Re: gnome-vfs/GIOChannel for parsing

[Jody Goldberg <jody gnome org>]

On Thu, Mar 06, 2003 at 12:35:31AM -0500, Colin Walters wrote:
> 
> On Wed, 2003-03-05 at 22:59, Jody Goldberg wrote:
> 
> > Storages contain streams in MS parlance.
> 
> How much of this are you advocating putting in glib?  Again, I can see
> the above file-in-a-file stuff being very useful, but only for
> relatively complex applications.  Do you really think all of it should
> go into glib?

We're specifying interfaces here not implementations.  The
relationships between stream and storage at the interface level seem
close enough and the additional cost trivial enough that I'd like to
see them go in as a pair.
 
> I just looked in the Debian package browser (aptitude) for programs
> which depend on libgsf-1.
There are no released applications that depend on it.  The library
itself is not even a year old.  It is being used in the apps you
name and will additionally be pulled into koffice, and OO at some
point.  However, that is not the point.  Some of the stream types in
gsf are not for general use (MS OLE) other might be.  The issue at
hand is whether its _interfaces_ are of general use.

> > An important use of the stream interface would be to support the
> > mime sniffing implementation being discussed else where.
> 
> Do you have a link for this?

The mime spec itself is being discussed on the xdg lists.  The
api notions I'd like to see as an app developer are just notes.
 
> I think one thing we will probably want is something like a
> GAutoStreamReader which looks at the stream buffer and attempts to guess
> at the character set and the EOL convention.  
reasonable.
 
> But MIME stuff opens up a whole big can of worms...glib doesn't depend
> on any kind of MIME database now.  Again, I really think this makes more
> sense in a separate library like gsf.
I only mention them in that there was recent discussion in another
thread on exactly that.

> > I'll try to be more explicit.  My meaning is that an api to support
> > asynchronous operations is orthogonal to the stream interfaces.
> 
> It's somewhat orthogonal, I agree.  I'm not saying it's a core
> requirement, but it will be needed.

certainly.
 
> > I don't see alot of use to some of the TextReader interfaces
> >     - get/initialize LifetimeService
> >     - hashing
> >     - equality
> >     - serializable
> 
> Most of this stuff is just inherited from the .NET object stuff I
> believe.

The inheritance from serializable, and the hashing/equality seemed
native.
 
> > On further examination of the .net Stream interface it seems
> > fundamentally different from my goals in gsf.  Its base 'Stream'
> > interface mixes in and out.  There is no way to divide them.  I
> > would be very much against using that as the primary abstracting in
> > glib.
> 
> Didn't we already agree to separate it into InputStream and
> OutputStream?

Yes, and by doing that we're now playing with a fairly fundamentally
different api than .Net.