Re: gnome-vfs/GIOChannel for parsing

[Havoc Pennington <hp redhat com>]

On Thu, Feb 20, 2003 at 03:01:16PM -0500, Colin Walters wrote: 
> 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.

I think you're starting from the wrong end of things here.  What I
would do is write up what a stream API is, what it's used for, how
it's different from GIOChannel, links to different existing stream
APIs (in GNOME but also in Qt, Java, etc.). Post that to
gtk-devel-list. Also get a bug open on bugzilla.gnome.org against glib
for a stream API.

For new APIs we like to do homework along the lines of 
 http://people.redhat.com/otaylor/fosdem2003/file-selector.html
A stream API writeup can be a whole lot shorter than that
but still we need a starting point to understand the problem.

Once we decide what the API should be like, and how it relates to
GIOChannel, we can figure out how to organize the libraries in
whatever way makes sense.

Havoc