Reply – Re: JOCL 'edge' branch: llb binding ..
Your Name
Subject
Message
or Cancel
In Reply To
Re: JOCL 'edge' branch: llb binding ..
— by Sven Gothel Sven Gothel
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

>
> -michael
>
> On 05/30/2011 02:33 AM, Sven Gothel [via jogamp] wrote:
> >
> > 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