Re: gnome-vfs/GIOChannel for parsing

[Havoc Pennington <hp redhat com>]

On Thu, Feb 20, 2003 at 12:21:02PM -0500, Colin Walters wrote: 
> It does raise some questions though.  Obviously not all of libgstream
> can go into glib; it has a GnomeVFS stream type.  So maybe just the
> generic GStream and GFdStream could be in glib, and then GVFSStream
> would go in gnome-vfs?
> 
> The alternative would be to keep libgstream whole, and have it be right
> above gnome-vfs in the dependency stack.
> 
> I'm kind of leaning towards the latter.  Keep GIOChannel for glib-only
> apps, and full GNOME apps could use libgstream.

That sucks in several ways:

 - gstream is really too small to be its own library

 - we have both GIOChannel and GStream which is confusing 
   for people learning the API and is just plain old bloat

 - GLib-only apps can't use GStream

The long term direction absolutely should be that the whole basic
devel platform (stuff we expect say >50% of apps to use) should be a
single coherent whole with no duplication. So anytime we have say two
stream APIs with the same basic purpose, one of them has to be
considered deprecated in the big picture, at least on a longer term
(2-3 year) timeframe. The (general purpose) libs above GLib/GTK should
be shrinking not growing over time, if they start growing we have a
problem. Special purpose libs such as a database API for example
should of course remain separate modules.

In short it's a bug if we have "GTK apps" and "GNOME apps" - GTK
should be a complete framework to write an app that works well on
UNIX/Linux X11 desktops, with a single coherent API with coherent
documentation, and apps should not be tied to the desktop environment
they are running under.

I've always been opposed to adding platform library features that are
"deprecated from the start" due to this. Library features that aren't
in our guaranteed-ABI platform (eel for example) are a different
thing, it doesn't really matter if they end up deprecated.

Havoc