Re: [GNOME VFS] gob inside gnome-vfs ...

[James Henstridge <james daa com au>]

Havoc Pennington wrote:

> Seth Nickell <snickell stanford edu> writes: 
>  
>
> > The GnomeVFS changes only affect module ABI and source compatibility,
> > and even then only for a limited number of modules that actually used
> > the old API. I believe there's precedent for this in GTK already, which
> > even versions its modules so it can change for 2.2 (GnomeVFS has
> > traditionally provided progressive versioning with full backward compat,
> > you just didn't get new functionality on those modules). We're planning
> > to radically break module ABI for 2.2, but provide a compatibility mode
> > for loading old-style modules. The new interface will be GObject based,
> > but old modules should be loadable using a GObject wrapper, so user's
> > shouldn't be negatively affected.
> >    
>
> If the removed functions are for modules only and not exported in the
> normal headers then that works. If the removed functions could have
> been used by applications and there was no indication that apps should
> avoid them, then it does not work. "indication" really needs to mean
> something like #define GNOME_VFS_PRIVATE_MODULE_INTERFACE to get these
> prototypes, similar to PANGO_ENABLE_BACKEND. i.e. not just reference
> docs notes.
>  
The gnome-vfs module headers are in a completely separate directory (you 
need to add an extra -I command to cflags, or add the pkg-config 
gnome-vfs-module-2.0 to the list you require in configure.in).  That 
makes it pretty difficult to get confused ...

>  
>
> > We plan to keep GnomeVFS 2.0 and 2.2 ABI compatible for client calls,
> > though we're going to need to do a release of GnomeVFS 2.0.1 with some
> > padding of several structs to make sure this is really feasible.
> >    
>
> You had better hurry - the release candidate is long since out, and
> the release is in less than a week. Changing the ABI after that is not
> OK - which should not need to be said. Most other modules went through
> and added padding a long time ago. Libraries depending on gnome-vfs
> are already ABI frozen, and in principle they were not supposed to be
> ABI-frozen until all their dependencies were. Moreoever, the .0
> release of every lib was supposed to be ABI-frozen, so 2.0.0 should
> have been. Now everyone has to rebuild everything at the last minute
> to add this padding. :-(
>
> Would it be acceptable if GTK 2.0.0 and 2.0.1 were not ABI compatible?
>
> You should plan for 2.2, 2.4, and even 2.6 to be ABI-compatible; the
> general plan from everyone I've talked to is that GNOME is not moving
> to an ABI-incompatible platform for at least 2 years, and we are
> trying for a release every 6 months. So that's at least 4 releases on
> the same ABI.  Of course gnome-vfs need not have new releases to
> accompany each GNOME release. But if you break the ABI, I don't think
> GNOME will use the new gnome-vfs for at least 2 years. Perhaps 3 or 4.
>  
Of course, most of the structs in gnome-vfs can only be legitimately 
allocated by gnome-vfs functions, and there is no subclassing to worry 
about (and things like GnomeVFSFileInfo have a flags field to say which 
parts of the struct are valid), so it should be pretty easy to add stuff 
to the end of the structs.  Or is Seth proposing to add padding to the 
starts of the structs?

James.

--
Email: james daa com au              | Linux.conf.au 2003 Call for Papers out
WWW:   http://www.daa.com.au/~james/ |   http://conf.linux.org.au/cfp.html