Re: gnome-vfs/GIOChannel for parsing

[Colin Walters <walters debian org>]

On Thu, 2003-02-20 at 13:08, Havoc Pennington wrote:
> 
> That sucks in several ways:
> 
>  - gstream is really too small to be its own library

Yeah...well, after it gets character I/O it will be a bit larger, but
still quite small, that's true.

>  - 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

Ok, true.

> 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.

Ok.  Then you're in favor of putting the core of a GObject-based stream
library into GLib?  If that could be done, I'd be quite happy.  We could
then mark GIOChannel as deprecated.

I guess it would feel a bit strange though, because currently GLib is
split into two conceptual pieces: GLib, which is basically C utility
functions, and GObject, which just implements the object framework. 
Right now it doesn't actually provide any specific classes itself.

So if we do put a stream library in glib, I think we'd be moving more
towards an architecture where glib is the implementation of the GObject
"language".  We'd be creating a kind of internal third component in
glib; maybe call it GCoreLib or something.  It would have to be a third
component, because GLib's internal dependency stack has GObject on top
of GLib.  Creating a third component seems to me to be a fairly big
decision, and I'd like to be sure that it's acceptable before putting a
lot of work into creating it.