Re: Problems with the Stream interface

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael@helixcode.com> writes:

> Hi Maciej,
> 
> On 11 Aug 2000, Maciej Stachowiak wrote:
> > I have a proposal for how to solve this problem. Essentially, we need
> > to make the Stream interface asynchronous by design. We can start with
> > the current Stream interface and convert all calls to not return a
> > value and take some sort of response listener object to which they
> > will deliver the results when ready. This is much like the gnome-vfs
> > CORBA interface for asynchronous I/O.
> 
> 	Ok; I like the idea, but it would be good if you could post a
> fleshed out idl for your idea.

I will post IDL soon; I just wanted to scope out general opinion on
this idea first.
 
> 	I also think that the best way to do it is for each 'AsyncStream'
> interface ( which the C wrappers will make it easy to write ), creates a
> standard Stream interface to allow easy scripting; so this would mostly be
> a way of increasing the prevalence of the async interface and encouraging
> people to use that as the default implementation while not making life
> difficult for other, particularly scripting, languages.

Here is my proposal for how to make life easy for PersistStream
implementors:

* We add an AsyncStream interface.

* The PersistStream interface's methods all take AsyncStreams, not
  Streams

* Bonobo provides a standard component that implements the current
  Stream interface, and takes in an AsyncStream which it wraps to look
  like Stream.

This way, containers are free to be as async as they want to be, but
controls that want to be lazy and use a synchronous interface have a
way to wrapp the asynchronicity to look sync, regardless of what
language they are implemented in.

Now arguably this makes life though for PeristStream users (the side
that is actually streaming data to/from the component) since they must
always implement the AsyncStream interface. I believe this is not a
major problem for the following reasons:

* Bonobo provides standard Stream/Storage implementations, so you
  rarely need to write your own.

* It's perfectly valid to make the response callback to an AsyncStream
  call from within the call itself, effectively making things
  synchronous from the point of view of the stream implementor.

This all, of course, brings up the fascinating question of how
PersistStorage/Storage ties into all this. Nautilus does not care
about those interfaces right now, but I can see how synchronicity
there can also be a problem. Should I address this issue in the IDL
proposal I will post shortly?

 - Maciej