Re: [java-gnome-hackers] a possible merge strategy

[Gerald B. <ger...@gm...>]

As an outsider looking in it seems like this bioils down to the following:

    1. This project currently uses Auto-Generation of a private API from the
.defs files for Gtk etc.
    2. This is then wrapped with a public, hand-constructed,
hand-documented, and intimately reviewed API
    3. GObject/Gtk now provides an introspection/reflection API to make it
much easier for language binding to auto-generate their binding API
    4. Colin's project uses the new introspection API to do just that,
providing nearly complete coverage (caveat: not all Gtk libs are based off
GObject, e.g. Cairo, and so are not able to be thusly introspected)
    5. Colin (and his ilk) would like to see complete coverage more than
ideal public API
    6. Stefan (and his ilk) would prefer a "Java Friendly" and well reviewed
public API more so than immediate complete coverage

Could a possible compromise be:

    1. Auto-Generate a public, full-coverage API using the introspection
method
    2. Call this API, though public, not recommended for direct usage and
clearly document that it will change whenever the underlying Gtk API's
change
    3. Create the "Java Friendly", well reviewed, well JavaDoc documented
public API to wrap the above generated API

This provides a couple of advantages:

    1. Nice, Java-friendly, stable public API (though possibly incomplete
initially) for those who wish (like me) to use something Java-friendly
    2. Full-coverage, near immediate Semi-Public (for lack of a better term)
that closely tracks the underlying Gtk API's

This, to me, seems like the best of both worlds. Thoughts?

Kind Regards,

Gerry B.


On Thu, Oct 16, 2008 at 10:54 AM, Stefan Prelle <st...@pr...> wrote:

> Hi Colin,
>
> On Thu, 2008-10-16 at 10:34 -0400, Colin Walters wrote:
> > Anyways - so you are saying you want to continue on java-gnome's path
> > of being a hand-crafted API for some parts of GTK+ and below,
> > continuing to expect that at some point many new people will appear
> > and write/maintain bindings with custom documentation for every
> > GObject library out there?  You see no role for having a correct
> > generated API to fill in gaps in the wide variety of libraries
> > java-gnome hasn't even looked at?
>
> Provoking question :)
>
> I would put it differently. We already use autogenerated APIs but take a
> different approach then you do. This may be combined but it will be a
> tough piece of work. I'd like to see cooperation on that part.
>
> Regarding coverage: If we chose to go your way for the yet not covered
> APIs and provide an unreviewed public API, we can not change the API
> later on if we find it unsuitable since this would break compatibility.
> So we would need to review every covered API down to every method. This
> is in fact the same level of work we now have when we review and cover
> APIs provided from our code generator.
>
> Or let me put your provoking question the other way around: You prefer
> to risk having a crappy API which cannot be changed later just to have
> the API immediately?
>
> Cheers,
>  Stefan-who-hopes-this-won't-end-in-a-flame-war
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>



-- 
Gerald E. Butler
http://bffoss.com
ger...@gm...