Re: gnome-vfs/GIOChannel for parsing

[Colin Walters <walters debian org>]

On Mon, 2003-02-24 at 00:29, Jody Goldberg wrote:

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

Ok, I can understand that.  I will separate out the proposal into
InputStream and OutputStream.

> There is also no mention of a Storage
> interface to go with it. 

Storage interface?  Could you explain?

>  The Directory and DirectoryInfo classes
> seem more directed towards path parsing.

Yes; I am not sure about putting them into GStream.  It seems cleaner
for us to just use the API for the filesystem you're accessing, be that
the local system or GnomeVFS.

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

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

In C# they are abstract classes, as they should be in GStream.  But what
do you mean by "simple implementations"?  What would they read from?  C#
has both StreamReader and StringReader for example; both of these read
character data from a source.

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

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?

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

Ok, that seems reasonable.

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

Ok, I agree.

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

Ok, done.