Re: Plans for gnome-vfs replacement
- From: Hans Petter Jansson <hpj novell com>
- To: Alexander Larsson <alexl redhat com>
- Cc: "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>, "gtk-devel-list gnome org" <gtk-devel-list gnome org>
- Subject: Re: Plans for gnome-vfs replacement
- Date: Tue, 19 Sep 2006 16:24:49 -0400
First off, thanks for starting this debate. It looks like gnome-vfs is
in for an awesome overhaul. Some comments on streams below.
On Mon, 2006-09-18 at 18:12 +0200, Alexander Larsson wrote:
> I've been doing some initial sketching of the glib API, and I've
> started by introducing base GInputStream and GOutputStream similar to
> the stream objects in Java and .Net. These have async i/o support and
> will make the API for reading and writing files nicer and more
> modern. There is also a GSeekable interface that streams can
> optionally implement if they support seeking.
We may have a lot to gain from thinking about what we need in the low
and intermediate level of the I/O stack now that we're discussing a
In addition to VFS, these should facilitate network protocols that don't
map to file system operations - for instance, protocols for instant
messaging, collaboration and games.
Due to the need for asynchronous - and often multiple levels of -
tokenization and events, this type of application quickly becomes a mess
of callbacks into a complicated state machine.
I'm thinking an element-based approach on the low-level end, similar to
but simpler than GStreamer's, might alleviate this problem. It would
make complicated stream code clearer and more reusable because there's
an agreed-upon way to split tasks into multiple state machines
(encryption, compression, flow rate limitation, tokenization, parsing,
etc). You could also easily insert a "debug element" into a stream to
divert an ASCII dump to a second stream for inspection - much nicer than
lacing a monolithic I/O loop with g_print()s.
Tokens and events could be represented by GObjects inlined in the
Of course, not all applications need such functionality, but that's just
a matter of wrapping this in a higher-level, more rigid API.
Also, what's your thinking on supporting asynchronous DNS lookups,
representing IP addresses, TCP/UDP sockets, etc? We currently don't have
any clear platform solution for that.
"...you cut a piece, and as you're taking it off of the fork the
main piece of the filet may be floating up out of the plate, but
you stab it with your fork and put it back down in, and if you
do it carefully, the surface tension of the gravy will keep it
- Russell Schweickart
] [Thread Prev