Paul Sandoz <[EMAIL PROTECTED]> writes:
> >> If you use async then the GUI becomes very sluggish
> >> in debug, not sure what its like in release, as per
> >> bug 50104.
> >>
> >> I am testing against an internal LDAP server which
> >> contains all Sun employee info, so it is very
> >> responsive.
> >
> >OK, that makes sense. You might want to try apply danm's patch in
> >50104 with async proxies and see if it makes any difference. Either
> >way, if you could comment in the bug that'd be great... because we
> >really should apply pressure to get 50104 fixed, if at all possible.
> >
>
> Done.
Great; thanks!
> I am curious to see how things behave in a release
> build. I am gonna kick one off and see what
> happens.
Cool...
> One thing i pointed out in bug 50104 is the fact that
> asynchronous RDF datasources may be tied to the UI
> thread for notification. Observers other than XUL
> may not care that the notifications occur on a
> different thread. Thus the address directory datasource
> aan the js LDAP datasource are in some sense bound to
> the UI thread.
> If it was up to the XUL Observers to decide how to
> process the events then there may be scope for
> optimization, via the choice of a special event
> queue and proxying of i.e. move the responsibility
> away from the datasource.
Hmmm, that's a good point. The way LDAP XPCOM SDK deals with this is
that it just makes you pass in an object which implements an
nsILDAPMessageListener as a callback, and if the caller needs to
ensure that the callback happens on some particular thread, then the
caller passes in a proxied callback object. Perhaps RDF and it's
callers (including XUL) could be made to work this way as well. It
would presumably require one tree whomp, but shouldn't be very hard.
Adding .rdf and .xpfe to see what the owners of those modules think...
Dan
--
