Re: oaf async activation

[Miguel de Icaza <miguel helixcode com>]

> Yes, I already did a gross hack in Nautilus to work around the fact
> that the PersistStream, PersistFile and ProgressiveDataSink interfaces
> are all synch, and potentially slow (espeically the first two). The
> Bonobo maintainers seemed highly disinterested in having a fix for
> this in Bonobo, and the Evolution hackers told me they didn't care if
> the Evolution UI got blocked by these kinds of problems. (In case you
> care, my solution was to have a separate process to handle these kinds
> of components; the native Nautilus::View interface is all async-safe,
> so it can be handled by Nautilus directly. See
> nautilus/src/components/adapter for details).

I dont think it was a lack of interest, but rather that no good
solution was proposed.  Maybe i am wrong, but I am definetly
interested in fixing this.

Do you have any suggestions for this?  We have until monday to change
Bonobo :-)

> The logical conclusion of supporting async architecture is adding
> async versions of any call that does something potentially slow, if
> apps want to be truly non-blocking. That bloats the API a fair
> bit. However, many in the GNOME community still have concerns about
> the portability of threads and their accessibility to the average
> developer.

I am still convinced about this myself.  We are using threads in
Evolution as a stop gap measure, the Evolution team is interested in
revamping Camel to have an async api and asyncronize the entire
pipeline.  

Miguel.