Re: gnome-vfs/GIOChannel for parsing

[Colin Walters <walters debian org>]

On Thu, 2003-02-20 at 04:51, Michael Meeks wrote:

> 	Ok; so it looks good enough to me, but I'd cut down some of the bulky
> API method complexity. If you want people to sub-class it.
> 
> 	I suggest:
> 
> enum {
> 	CAN_SEEK  = 0x1,
> 	CAN_WRITE = 0x2,
> 	CAN_READ  = 0x4
> } Attrs;
> 
> 	Attrs get_attrs (GStream *stream);
> 
> 	or somesuch - a single simple method instead of three.

Good idea; done.

> 	I'd also look at whatever GStreamer uses for a stream API.

I don't think it really has a stream API, at least not in any sort of
traditional sense.  It has source elements and sink elements, which push
and pull buffers.  I guess maybe you could think of the entire GStreamer
API as a "stream" API, but it would be waaaaay overkill for just reading
a file :)

> 	I'm not convinced that read_byte belongs in the lowest level of this -
> I'd do that with a chained caching sub-class that stacked on top of a
> generic stream.

This is just like in the C# stream API.  If the stream implementation
has a buffer itself (like GVFSStream), then it's more efficient for it
to provide an implementation of read_byte which just peeks into that
buffer.

Now, maybe you could argue that GVFSStream and the like shouldn't have a
buffer at all.  I would tend to agree...but I just did what C# does for
their FileStream.  Maybe they had a reason...

> 	Similarly, there seems to be a confusion between gsize and
> GnomeVFSFileSize - eg. 'read' - why is that ? [ presumably if the API is
> going to be as low down the stack as it needs to be to be useful it
> should use glib types only ].

Yeah, I'll replace the GnomeVFSFileSize bits with something
glib-equivalent.

However, I don't think it makes sense to use GnomeVFSFileSize (i.e. a 64
bit type) for parameters related to buffer sizes.  A gsize (i.e. size_t)
should represent the largest addressable space of a buffer.  Using
GnomeVFSFileSize to pass buffer sizes is overkill on 32 bit systems,
because most 32 bit systems can't have a buffer larger than 2^32 bytes. 
Even if they can, the C standard doesn't really support it.  Functions
like 'memcpy' only operate on size_t.
 
Honestly I don't know why GnomeVFS uses GnomeVFSFileSize for stuff
dealing with buffer sizes.  It's unnecessary and slow on 32 bit systems.

> 	Also - there is a reason 'write' returns the number of bytes written -
> non-blocking writes ( a rather crucial feature ). 

Yeah, I am planning on porting over the C# async I/O stuff.

> In a similar vein,
> some way to make the stream non-blocking is important IMHO - along with
> the ability to get a fd to poll on for state changes;

Non-blocking should be taken care of by async I/O.

I'm not sure what you mean by state changes.  Stuff like async I/O
completion?  That would be handled by a regular GObject signal.

> 	Looks nice so far. More work required though ;-)

Yeah :)

> 	My feeling is still that even if you come up with a near perfect
> solution, you'll be stultified at the point of actually getting it
> anywhere near glib.

Havoc's comments are heartening in this respect!

It does raise some questions though.  Obviously not all of libgstream
can go into glib; it has a GnomeVFS stream type.  So maybe just the
generic GStream and GFdStream could be in glib, and then GVFSStream
would go in gnome-vfs?

The alternative would be to keep libgstream whole, and have it be right
above gnome-vfs in the dependency stack.

I'm kind of leaning towards the latter.  Keep GIOChannel for glib-only
apps, and full GNOME apps could use libgstream.