JOCL 'edge' branch: llb binding ..

Using multiple low level classes w/ a verbose suffix 'Binding'
separating the CL API is IMHO too much.
Especially since those llb classes are in the public namespace.

A simpler approach IMHO would be to use JOGL's public API interfaces
and to leave out some of the CL API methods if desired, hooking 'em up w/
public manual methods which use those 'llb' ones.

This would remove the public llb package and keep it all in one place
ie
  com.jogamp.*.CLContext public API interface and
  jogamp.*.CLContextImpl private implementation

Now we have 'CLContext' and 'CLContextBinding' in public,
where the latter maybe be useful for the public .. or not.

A one stop for a CL context might be easier and reduce confusion.

~Sven

  they are only implementation details which simplify my current project
(not open source).

public LLB (not recommended to use in most cases):
com.jogamp.opencl.llb.CL (exposes full core functionality)
com.jogamp.opencl.llb.gl.CLGL (exposes opengl extension)

HLB (recommended, thats what all the samples use):
com.jogamp.opencl.opencl.*

(nothing changed)

the binding interfaces probably won't be public in the final release. CL
extends all binding interfaces and exposes therefore full functionality.
The binding interfaces represent the object model of the CL API which
will be needed internally. The last time i used LWJGL they did something
similar for GL which allowed easy composition of the
features/versions/extensions you where using in the app.

The edge branch is fully backwards compatible nothing has to be modified
in client code. (as i said before, impl detail)

edge -> experiments aka bleeding edge, use at your own risk
master -> main branch

-michael

On 05/30/2011 02:33 AM, Sven Gothel [via jogamp] wrote:

On Monday, May 30, 2011 04:13:46 am Michael Bien [via jogamp] wrote:
>
> The last time i used LWJGL they did something
> similar for GL which allowed easy composition of the
> features/versions/extensions you where using in the app.

LWJGL is a diff story, and I the benefit of creating separate namespaces (not objects)
is questionable .. since 'functionality' in the GL case is more based on the ctx type,
ie GL2, GL3 ..

For CL, things are similar. Well, diff types for diff purposes like ctx and buffers
are ofc natural and as you said, they already existed. This wasn't the point.

>
> The edge branch is fully backwards compatible nothing has to be modified
> in client code. (as i said before, impl detail)

The point is the impl. detail itself.
If hiding such in the jogamp.* package, this might not matter.
However, I am unsure about the benefits of enforcing a new layer, just by taste.

A 'private project' as you stated, hinting a proprietary use,
is for sure everything but transparent and possible to review.

>
> edge -> experiments aka bleeding edge, use at your own risk
> master -> main branch

As it is today, both branches are incompatible with the jogamp tree,
but I will keep this one for later if it still applies.

~Sven

  On 05/30/2011 05:03 AM, Sven Gothel [via jogamp] wrote:
> On Monday, May 30, 2011 04:13:46 am Michael Bien [via jogamp] wrote:
>> The last time i used LWJGL they did something
>> similar for GL which allowed easy composition of the
>> features/versions/extensions you where using in the app.
> LWJGL is a diff story, and I the benefit of creating separate namespaces (not objects)
> is questionable .. since 'functionality' in the GL case is more based on the ctx type,
> ie GL2, GL3 ..
they are doing both functionality and context separation - but this was
only an example.

> For CL, things are similar. Well, diff types for diff purposes like ctx and buffers
> are ofc natural and as you said, they already existed. This wasn't the point.
>
>> The edge branch is fully backwards compatible nothing has to be modified
>> in client code. (as i said before, impl detail)
> The point is the impl. detail itself.
> If hiding such in the jogamp.* package, this might not matter.
> However, I am unsure about the benefits of enforcing a new layer, just by taste.
there is no additional layer. There has always been the generated LLB
and the handwritten OO HLB. No enforcements at all, again: nothing
really changed in public API.

>> edge ->  experiments aka bleeding edge, use at your own risk
>> master ->  main branch
> As it is today, both branches are incompatible with the jogamp tree,
> but I will keep this one for later if it still applies.
my jocl repository on github is the jogamp repository - i never
reverted, rebased or did anything which would break compatibility to
other repositories. This would be far to much communication effort in a
distributed versioning system like git.

-michael

> ~Sven