Re: GObject-based generic I/O

["James M. Cape" <jcape ignore-your tv>]

On Tue, 2004-02-17 at 03:59 +0300, Mikhail Zabaluev wrote:
> Hello,
> 
> Some time ago, in a mailing list not far away,
> a brief discussion happened about an extensible, pluggable I/O API
> at the dependency level of glib or slightly above.
> Independently, this Bugzilla entry existed for a while:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=106686
> 
> This finally led me to put together a humble attempt at a generic I/O
> framework based on GObject. It's now available here:
> 
> http://people.altlinux.ru/~mhz/software/sources/goio/goio-0.1.1.tar.bz2
> 
> The following ideas went into the design:
> 
> - Instead of a monolithic kitchen-faucet-and-sink object, create a
> variety of classes representing different kinds of I/O entities. Each
> class implements one or more concise interfaces that determine what
> you can do; GoioReadable, GoioWritable and GoioFile are the interfaces
> currently defined. For example, a socket object (not in the library
> yet) would be readable and writable, but it won't exhibit methods
> reserved for files. An iconv converter for input would implement
> GoioReadable and use another GoioReadable as a source, and so on.
> 
> - Make use of GObject for runtime type checks, refcounting and
> signalling, to allow assembling I/O processing chains easier and safer.
> 
> Thanks to Jody Goldberg for insights.

I talked to jody and walters about this the day before yesterday, and
mmeeks about an hour ago, and started working out a writeup and
GInterface setup. It looks like you're a little farther along, but I'll
share my thoughts:

1.) GStream is a much cooler name :-)
2.) Typically interfaces are called "Iface" in the actual code (as they
are separate from "base classes", which are implemented as abstract
GObjects in glib).
3.) A SeekableIface could install a "seek-offset" property which
implementations use to actually set the offset as needed. This
eliminates the need for the seek/tell methods (and would free up the
"File" namespace for things like GnomeVFS).
4.) There should be a means to read/write ancillary data along with the
standard data buffer (the pointer/size args). This is required in some
circumstances (such as ucred-verified UNIX socket networking (man 7
unix), or FS metadata), and opens up a wide range of other possibilities
-- most obviously, GStreamDirectoryIface ;-).
5.) Async IO is a must for networking, and a plus for files.
6.) Great work (especially beating me to the punch by writing code while
I was writing a proposal and got bogged down on the "existing APIs"
part).

Let me know what you think (especially about the name), I can come up
with a counter-tarball or patch in an hour or so :-).

-- 
Peace,

    Jim Cape
    http://ignore-your.tv

    Everyone has their own Truth, but there is only one Honesty.