Re: GNOME ABI review

[Michael Meeks <michael ximian com>]

On Thu, 2003-08-07 at 05:34, Havoc Pennington wrote:
>  gnome-vfs has a sprawling API with UNIX-looking semantics. However, 
>  the backends don't conform to UNIX semantics (or really any semantics
>  at all). Moreover, we make up URI schemes, and otherwise suck.

	Well; I'm sure someone will say it's not a URI - because it isn't ;-)
however we do use something that looks like one. I don't know that's a
massive problem, as long as it's well defined.

	As for not conforming to UNIX-y semantics have you looked at some of
the more exotic Linux kernel network file-systems recently ? quite
probably we don't need very extremely strong semantics at this level -
particularly for document I/O - which has to be the brunt of what we
really want from the VFS IMHO.

>  The big ugly problem is that different apps (OpenOffice, etc.) 
>  see different sets of usable URIs - this simply _must_ be solved
>  in some way.

	Right - this is because gnome-vfs has no way to 'get_supported_uris'
that is externally exported; thus about the only sane way you can work
out what URIs gnome-vfs supports, is to parse the mime database, look up
your own app, and grab out the list of supported URIs.

	Which is a shame;

>  A better gnome-vfs might have a very minimal required interface for
>  each backend, such as just listing files and getting their contents
>  in a single large block. Then additional interfaces discovered via a
>  queryInterface()-style approach would add features such as file
>  modification, streaming read/write, getting file permissions, file
>  copy, or whatever.

	That would work well; my feeling is that most applications couldn't
care less about the vast majority of capabilities here; all they want is
a simple, synchronous, usable, (GObject?), stream API - uncluttered by
mess and random text encoding fluff ;->

> So that's my mega-troll of the month - but seriously, I hope everyone
> will give it serious thought.

	Well - I don't think this was nearly trolly enough ;-) you forgot all
the ORBit2 / libbonobo problems ;-)

	Mercifully, ORBit2 is now really quite good wrt. exported ABI, which is
particularly helpful since the standard ties us to the existing names /
types. Typecode is unfortunately exported - but since we have to
construct those in skels efficiently that's fairly unavoidable.
Thankfully, CORBA_Object, the ORB, all the POA bits etc. are all
implementation private so - we could even move them to GObject when/if
we get a thread-safe GObject. Also, all the transports are encapsulated
and switchable - which is hopeful.

	Libbonobo is somewhat more at the mercy of the elements; we could do
some /* private */ tagging of some of the BonoboObject members, and we
have some gpointer dummy[4]; expansion space in misc. classes, IDL
interfaces, private data pointers [ although glib seems to be poised to
render them obsolete happily ;-].

	libbonoboui OTOH exposes vast swathes of deprecatable cruft; the dock
and it's own toolbar impl. being the most pernicious; hopefully though
these can be farmed off into some compat sub-directory and forgotten
shortly - switching to Gtk 2.4. Leaving, not a whole lot in libbonoboui
beyond Plug/Socket wrappers / zoomable and whatever we'll still need for
compatibility of the BonoboUIEngine & friends.

	Regards,

		Michael.

-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot