Re: GObject-based generic I/O
- From: "James M. Cape" <jcape ignore-your tv>
- To: Mikhail Zabaluev <mhz altlinux org>
- Cc: gtk-devel-list gnome org, gnome-libs-devel gnome org, jody gnome org
- Subject: Re: GObject-based generic I/O
- Date: Tue, 17 Feb 2004 05:13:36 -0600
On Tue, 2004-02-17 at 03:59 +0300, Mikhail Zabaluev wrote:
> 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:
> This finally led me to put together a humble attempt at a generic I/O
> framework based on GObject. It's now available here:
> 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"
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 :-).
Everyone has their own Truth, but there is only one Honesty.
] [Thread Prev