Re: GObject-based generic I/O

[Mikhail Zabaluev <mhz altlinux org>]

Hello James,

On Tue, Feb 17, 2004 at 05:13:36AM -0600, James M. Cape wrote:
>
> 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 :-)

I considered the name, but I recall it's been used for
something else... I mean, apart from GStreamer, which would be a
cause of confusion as well.

> 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).

Agreed. Any further hints at proper Gtk/GNOME coding practices
are greatly appreciated.

> 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

I can't follow you here. goio_seek/goio_tell are meant to be delegated
to the respective file calls more or less staightforwardly. This
additionally ensures that, had the underlying file position been
tampered outside of the object representing it (and I'm going to provide
handles/descriptors out of the implementations), the object's methods
report it correctly anyway.
What are the benefits of using a property vs. a couple of methods?

> (and would free up the
> "File" namespace for things like GnomeVFS).

Yes, I admit Seekable is better here, because that's basically what this
interface adds, and "File" is too loaded a metaphor.

> 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.

Whether or not all this should be fit into this framework, depends on
what you want to use it for. In my view, it's useful to assemble
chains for processing synchronous (if non-blocking) I/O streams, e.g.

       --[-> optional SSL decrypt --]-> iconv reader ->
      /                                                \
socket                                                  client
      \                                                /
       <-[-- optional SSL encrypt <-]-- iconv writer <-

Also, it allows components to just use the abstract I/O interfaces for
anything that can be read from/written to, and not sweat about
details, making a higher degree of interoperability and reuse
possible. So a highest common denominator-y approach to the interfaces
could be appropriate here.

As for the curious ways, those are too many to encompass.
My solution to that, if somewhat half-baked, is to
provide the actual handles and descriptors for anyone wishing to
exploit them.
I don't expect this API to be used in a high-volume server
context that would justify use of async IO. And on the desktop,
I feel, async is better fit for GnomeVFS which already does something
to that effect.
Directory browsing -- I don't like the idea of it tied to the stream
I/O. However, a directory-like storage access interface could peruse
goio to access individual files/streams.
Anyway, if you have any drafts for that, I'd be glad to take a look.

> 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).

Funny, I had this stuff laying in plans for about 6 months, being
preoccupied with something else. Finally got to it only to run over
someone else's toes :) I hope this incidental outburst proves
synergetic.

> 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 :-).

You are thoroughly welcome :)

-- 
Stay tuned,
  MhZ                                     JID: mhz altlinux org