RE: bindings fifth toe [gnome sandal? :) [was RE: 2.4 Module List and Rationale (aka GEP10 and 11)

[Murray Cumming Comneon com]

Murray Cumming
murrayc usa net
www.murrayc.com 

> -----Original Message-----
> From: Luis Villa [mailto:louie ximian com] 
> Sent: Mittwoch, 19. März 2003 16:07
> To: Cumming Murray (COMNEON Linz); GNOME Desktop List
> Cc: sander_traveling yahoo co uk; ross burtonini com; 
> gnome-hackers gnome org
> Subject: bindings fifth toe [gnome sandal? :) [was RE: 2.4 
> Module List and Rationale (aka GEP10 and 11)
> 
> 
> [Firstly, BTW, this thread should really at least cc: if not 
> primarily be on desktop-devel-list, which is the specified 
> discussion thread for the current GEPs and presumably would 
> be for the library GEP when it gets written.]
> 
> [Secondly, am I going to return from my trip before you do, Sander? :)
> 
> On Wed, 2003-03-19 at 09:23, Murray Cumming Comneon com wrote:
> > > From: Sander Vesik [mailto:sander_traveling yahoo co uk]
> > > Just IMHO but it makes sense to not freeze non-finished stuff 
> > > and just leave 
> > > these out and add them in in the next release.
> > 
> > In the case of libgnomeuimm, I have considered freezing it in an 
> > incomplete state and branching because:
> > - The unstable part of the API, Bonobo, isn't used by most people.
> > - And that won't be finished any time soon.
> > 
> > Sometimes API stability is only for the sake of API stability.
> 
> It seems that it we stamp this with big warnings saying 'not 
> API stable' it's not really an issue. 

Sure. I was just talking about one wee part of the C++ binding.

However, it would be nice to clearly stamp certain bindings as API stable if
they are. It's a big deal. And it wouldn't be fair to stamp individual
stable bindings with a general "bindings aren't stable" warning.

> I was thinking, FWIW, that this would be closer to a fifth 
> toe for bindings than Desktop or Platform- just something to 
> point people at, get some publicity for, etc.
> 
> > > To me (but
> > > this might be just me) it makes even sense to go for a 
> > > consistent coverage for a potentially smaller  set of modules 
> > > than have a very mish-mash experience as to what is supported 
> > > by which binding. 
> > 
> > I think that might be an unreasonable aim for the bindings. And it 
> > would be unfair to some bindings if we had to only include 
> the lowest 
> > common denominator.
> 
> I'd suggest that the compromise here is to document what is 
> supported everywhere and then ship everything anyway. :) 
> i.e., a comparison chart in the release notes saying:
> 	gtkmm	pygtk	gtk#	gtk-perl
> gtk: 	yes	yes	yes	yes
> bonobo:	partial	yes	no	no
> 
> [values above pulled out of my ass, no idea if they are 
> accurate or not] or something like that.

Yes, though "partial", "complete+stable", and "none" might be better.

Actually, as soon as you start talking about lots of languages it gets very
hard to assess this stuff. The problems are:
- There are languages that don't have the same API/ABI considerations,
though they are sometimes similar.
- There are maintainers who don't understand the concepts of API stability
or versioning.
- There are maintainers who overestimate either their API's stability or
completeness.
And it's impractical for any group of people to assess all these issues for
all of the bindings. On the one hand it's nice to let people just volunteer
information but that would quickly devalue the API stability/completness
declarations of the bindings maintainers know what they are saying.

That's why this page isn't very informative and is fairly arbitrary and
vague when it mentions completeness:
http://www.gtk.org/bindings.html

However, it's probably going to be fairly simple for the most popular
bindings.

Murray Cumming
murrayc usa net
www.murrayc.com