Re: GNOME Namespace Management - ARC & GNOME

[Mike Hearn <mike navi cx>]

Brian Cameron wrote:
> One thing that makes GNOME a little easier to deal with is that
> most Sun customers do not build their own applications using the
> GTK+/GNOME stack.  Further, Sun discourages customers from
> depending on (linking against, for example) the GTK+/GNOME stack
> since the GNOME community doesn't provide strong enough stability
> guarantees.  

That's a shame but understandable. What do you recommend your customers 
use? Presumably not Java, as that has a similarly spotty record of 
backwards compatibility.

> Since Sun itself provides most of the core GNOME
> applications with Solaris, most breakages that have occurred to
> date have not been noticed by customers.  Still, there is the
> risk that a customer will start depending on them and will want
> Sun to fix bugs that cause their applications to  break when
> they upgrade to a newer version of GNOME.  Therefore, Sun is
> wanting to work more closely with the community to try and
> better ensure that such breakages are identified, fixed, and
> proactively prevented.

Great! Obviously that's good not only for Sun but for everyone in the 
Linux/BSD world building on GNOME as well.

> This is something that ARC is currently struggling with.  The GNOME
> stack is perhaps the most significant aspect of Solaris that is not
> developed internally at Sun.  Other exceptions include projects like
> Mozilla and the Xserver.  However, most of these projects take
> stability more seriously than the GNOME project and make more of an
> effort to follow standards/specifications that are well developed by
> organizations like w3c and X.org.  

It used to be the case that X was very stable, but that was primarily 
because as a project it was stagnant. Since the fork and move to Xorg, 
development has picked up and some breaking changes have been made. For 
instance I think old X libs have been dropped (libXaw?) and the new ARGB 
visuals are known to break some apps. You may wish to keep an eye on that.

For Mozilla I guess you're not counting the XPCOM APIs Mozilla exposes 
which historically haven't been stable at all (see the Adobe SVG Viewer 
fiasco). In Gecko itself compliance with W3C specs is good, or at least 
always has been for me. Serious rendering regressions happen but seem rare.

> Perhaps freedesktop.org will
> become a standards body with the same sort of clout as w3c or X.org,
> but that will probably take time, and more community dedication towards
> defining/following standards.

Let's hope so. Right now it's more of a collaboration forum than a 
formal standards body. Specs can and do change, sometimes old versions 
actually disappear from the website entirely, for instance the old 
vFolder text file spec.

> Although the file system interfaces that GNOME depends on are somewhat
> stable, they are poorly defined and are not well organized.  Sun feels
> that proper definition and good organization are part of what makes
> interfaces stable.  So Sun would like to see improvements in these
> areas before Sun would agree that they are generally stable.

OK, that seems to make sense.

> > /etc/gimp, External: how is this directory which is internal to an image
> > editor considered a stable interface?
>
> The gimp system-wide rc files are stored here.  Changes that a system
> administrator makes to such files to affect the behavior of gimp
> shouldn't break from release-to-release.  Or do you disagree?

No I don't disagree, I just didn't realise that upgrading without 
changing file formats was classed as an external interface.

What happens if the config system changes but migration code is in place 
so that the old config is moved to the new config on first run. Is that 
classed as a breaking change or not for such interfaces?

> User applications should be able to integrate their gconf data to these
> file locations and expect them to work from release to release.

OK, I don't know enough about gconf to comment here. I thought it was 
internal but I can see the schema files in there, so I guess not.

> It is the directory on Solaris where we let users know that they can 
> install gtk-doc's that they wish to generate.

OK. It'd be nice to have that formalised somewhere.

> Sun considers glib, pango, gtk and libglade to be the GNOME modules that it
> supports with the highest level of guarantee against breakage.  Since this
> is a GTK+ interface, we have to support it more than we support other
> parts of GNOME.

Yes, I was referring to the GTK+ developers. Is the gtkrc file 
considered as stable as the library API itself? I don't know. It almost 
certainly is but I never saw an explicit guarantee ..

thanks -mike