Re: Problems with the Stream interface

[textshell t-online de]

I think it is important to have such interfaces ayncronous, because i
hate to have to use threads just because some interface is broken(in
windows this is almost always the case). I'm not sure how this should be
done some CORBA tweaking or and different interface...

Anyway I strongly opt for an asyncronous standard Stream interface!




Maciej Stachowiak wrote:
> 
> I'd like to point out a very urgent issue that I have noticed in the
> design of Bonobo. The Bonobo::Stream interface is inherently
> synchronous by design. This is a problem, because it means that when a
> component is slow to load (because the Stream data is coming over the
> network, because it's loading a lot of data, or just because it's slow
> for some reason) it completely blocks the UI of the containing
> application.
> 
> 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.
> 
> It is a showstopper bug for Nautilus right now
> (http://bugzilla.eazel.com/show_bug.cgi?id=1994) - when you view text
> documents, images, or anything else handled by an ordinary Bonobo
> control or embeddable that does not implement the special Nautilus
> view interface, the whole Nautilus UI blocks while the component
> loads.
> 
> Note that this problem cannot be solved just by adding a new
> interface.  If a component provides only the synchronous Stream
> interface, it can stil block the UI, so just making some kind of Async
> interface available (ProgressiveDataSink is sort of a step in this
> direction), it will still block the UI; it doesn't help that some
> other components might implement an async interface instead or in
> addition. So we actually need to remove this synchronous interface.
> 
> I'd like to point out, as an aside, why this problem arises in Bonobo
> but not in Microsoft COM, even though we copied their design. On
> Windows, threads are used heavily to avoid blocking, so if you want a
> component to load a stream without blocking the app's UI, you just
> start a new thread. In GNOME, we use asynchronicity and callbacks as
> the basis of our application architecture; for this to work, all the
> interfaces you need must be async.
> 
> 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.
> 
> 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). This way, containers can be safe
> from having components block their UI while loading, but components
> are still free to be written in a hasty way that will make their own
> UI completely block while loading (granted, this is far less harmful).
> 
> I am willing to commit my personal time to fixing this interface
> soon. Does my proposed plan of action sound reasonable? I'd like to
> start working out a detailed design on this list as soon as possible.
> 
>  - Maciej
> 
> _______________________________________________
> gnome-components-list mailing list
> gnome-components-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-components-list