Re: gnome-vfs/GIOChannel for parsing

[Jody Goldberg <jody gnome org>]

On Thu, Feb 27, 2003 at 04:44:02PM -0500, Colin Walters wrote:
> Ok, I can understand that.  I will separate out the proposal into
> InputStream and OutputStream.
thanks.

> Storage interface?  Could you explain?
GsfInfile & GsfOutfile or in MS/Bonobo speak Storages.
The relationship between streams and storages is fairly incestuous.
It seems useful to work out the interface details together.
 
> > The buffer handling in gsf also seems more comfortable.  By allowing
> > the app to specify how to buffer the result the people who know
> > their read patterns (the app) can tune things.
> 
> Fair enough, I guess.  This is mostly an implementation issue though.

Stream::read is the core of any api.  The exact semantics of this
are quite important.  We're defining interfaces here not
implementations.  As an example in GsfInput I made what seemed like
a simple assumption and added a GsfInput::size method which assumed
that we could always know the size of the data to be read when it
was opened.  This is not true for bzip2 files.  Its this sort of
thing that needs to be hashed out now.
 
> This is the kind of stuff that should definitely go in gsf, I think. 
> I'm not avocating for merging all of Gsf into glib or anything!  I'd
> just like to take the core bits to read and write streams.  Gsf should
> still exist as a separate library, and will just build upon the core
> stream stuff.  Do you agree?

We are clearly talking to cross purposes here.  If we define a glib
based stream interface I would not want GsfInput/GsfOutput.  So yes,
I am talking about merging parts of gsf into glib.  I envision
something on the order of gdk pixbuf.  With a registry of known
formats and interface specifications in glib.  Anything less seems
pointless.

> > With respect to async i/o I could use some background on where you
> > see it as necessary.  It certainly seems useful, but hardly a core
> > interface requirement.  
> 
> See Michael Meeks' reply to this.

While it seems useful to have an interface for async i/o I still
fail to see how it would be the primary interface an application
used.   I suppose I'm looking at things from a file format
perspective rather than a transport layer, but either way it seems
like a set of convenience wrappers for handling this is the way to
go.
 
Please grab me on irc at some point to speed this conversation.  We
can post details afterward.  I have the feeling that we're not
talking about the same things.