Re: gnome-vfs/GIOChannel for parsing

[Jody Goldberg <jody gnome org>]

On Sat, Feb 22, 2003 at 06:04:06PM -0500, Colin Walters wrote:
> 
> http://web.verbum.org/~walters/files/stream/index.html
> 
> On Sat, 2003-02-22 at 13:14, Jody Goldberg wrote:
> 
> > I'll have alook at the C# interface next week to see what sorts of
> > adjustments you're looking for.  My design goal for gsf was to
> > simplify the lives of document centric apps, things that sucked in
> > blobs of structured content and streamed them back out.  As long as
> > your proposed interfaces handle those needs well it should be
> > feasible to meet in the middle.
> 
> Cool, it sounds then that we are of alike minds on this.  The hard part
> is going to be getting async I/O API right.
> 
> What do you think about importing libgstream into the Gnome CVS as a
> place to prototype the API?

I'm not enthused with parts the C# interface.  It would greatly
complicate the implementation of the various structured file
readers/writers in gsf to support simultaneous reading and writing
from a single stream.  There is also no mention of a Storage
interface to go with it.  The Directory and DirectoryInfo classes
seem more directed towards path parsing.

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.

Some of the interfaces, particularly the text reader/writer seem
nice and would be easy to adopt in gsf-input-textline.  Although it
is unclear to me what is gained by making those interfaces rather
than simple implementations.

Your requirements focus on the text read/write there are several
additional areas to be considered.

    - Structured files : the raison d'etre of gsf.  The stream
      interfaces are all about reading data with no consideration
      for what MS calls 'storages', or structured files.  This
      requirement is interesting in that the jury is still out on
      whether simple structured file support is sufficient, or
      whether we need full fledged file system in a file semantics.

    - to/from libxml : there are alot of gnome apps that are xml
      based.  It is important that we be able to transition data in
      and out smoothly.

    - Easy to retrofit stdio based apps.  Having some simple stdio
      style wrappers is important to ease transition.  When
      converting some of the older Gnumeric file format plugins this
      was a big help.

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.  I don't see a use case for a stream based
app to read chunks of data asynchronously.  It seems more likely that
a utility wrapper might be used to pull down a large chunk and
notify when ready for use by the stream handler in a syncrounous
fashion.  That sort of an arrangement makes the async input
completely orthogonal to the stream interface.

While you're welcome to work on the project in gnome cvs I'd like to
see a whole lot more discussion before code is generated.

PS
    gsf easily supports peeking at buffers and character based i/o.
    The trick is that it is not a requirement of the base GsfInput
    api.  It gets handled in a wrapper.  This simplifies the
    implementation of the various format handlers.  Please update
    your doc.