Re: gnome-vfs/GIOChannel for parsing

[Michael Meeks <michael ximian com>]

Hi Colin,

	You put your finger on the lack of a standard, functional stream API -
and it is a serious problem, albeit one receiving very little thought
generally it seems.

On Mon, 2003-02-17 at 09:27, Colin Walters wrote:
> I want something that has the power of both gnome-vfs and GIOChannel;
> remote file access *and* functions to do stuff like read lines and
> characters at a time (efficiently).  It might be nice to use our object
> framework here, and create a GStream class.  That way people could even
> extend it to do other wacky stuff.  But where would it go? gnome-vfs? 
> Then gnome-vfs would have to depend on glib-object...maybe that's not a
> big deal though.  Opinions?

	Well; there are some problems, gnome-vfs already uses glib and hence
GObject - that's no problem.

	Ideally - having a single I/O API would be best; however GIOChannel as
you point out is not a GObject but a semi-OO custom thing. This is
because glib doesn't depend on/use GObject - as a feature.

	Other issues might be that it's nice to have a GInputStream and a
GOutputStream separation - and this can simplify the process of writing
small, correct implementations. Then of course - there is the
seekability dimension that adds problems.

	There is the process of gathering requirements from various users:
libbonobo's Bonobo_Stream, gnome-vfs provides none, not having a stream
API :-), G_Streamer_ presumably has some thoughts on the issue, etc.

	Finally - there are the issues of pollability, non-blocking I/O, thread
safety and so on.

	Nevertheless - it's an extremely worthwhile project - I'd be most
pleased to have a few I/O / streaming GInterfaces that would do a good
job of standardizing this / moving us towards a more powerful and
integrated I/O model.

	Unfortunately - it's unlikely to be possible (pragmatically) to get
this into glib.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot