Re: Problems with the Stream interface

[Miguel de Icaza <miguel helixcode com>]

> This is a problem for applications in general. If we want to be able
> to handle large data sets, and have everything be network-transparent,
> we need this kind of loading to be async. I've been told it's not a
> problem for evolution because the relevant data sets are small, but I
> imagine in the future someone might send a 300-page Word document
> attachment, and the poor recipient will have to see the whole UI block
> while it gets streamed into the view component.

We are now using threads in evolution to avoid similar problems. 

> If we don't want to force components to be bother with the complexity
> of handling asynchronous I/O (an understandable goal), it should
> actually be possible to emulate the current synchronous stream
> interface in terms of the async calls (so the only IDL would be for
> the async stream interface, but the bonobo client-side wrappers would
> provide emulated synchronous calls). 

The problem with this approach is that it means that anyone
implementing the Stream interface outside of the Bonobo C
implementation will have to bother with the details.  For instance,
Perl components or Python components which have nothing but the most
minimal runtime available.

But what is exactly the problem you are facing here Maciej?  

I do like to some extent the idea of having a callback-based system to
deliver the async features, but the Stream interface as it stands is
just a simple file-IO like interface.  I would very much like to avoid
replacing it to be asyncronous.

Miguel.