Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> Dan Mosedale <[EMAIL PROTECTED]> writes:
> >
> >> We are in the process of writing an LDAP webtop
> >> implementation using the LDAP XPCOM directly.
> >> We can be clever in how we return data by
> >> implementing a class which is an enumerator
> >> and also an LDAP message listener there by
> >> (i assume!) allowing the object to be passed
> >> up through the singular directory data source
> >> without blocking until all results have been
> >> obtained (e.g. get child cards). The same can
> >> be done for querying.
> >> I think the js datasource does somthing similar.
> >> Just gotta make sure that the container (or queue)
> >> which stores incomming results is guarded for re-entrant
> >> code when entries are removed or obtained?
> >
> >Sort of. But part of the reason this works in the datasource is that
> >the users of the datasource are assumed to have an nsIRDFObserver
> >sitting around waiting for updates. So if the results of a particular
> >query aren't already cached as an RDF delegate object, an empty
> >enumerator is returned, and the results are called back (unrelated to
> >the enumerator) with nsRDFObserver::onAssert() one at a time as they
> >arrive. The only things that need to be threadsafe are the delegate
> >objects, and (I assume) the JS engine provides that threadsafety for
> >us under the covers. But I could be wrong. Peter V, can you confirm
> >or deny this?
> >
>
> Ah, i understand more now.
> The LDAP message listener components need to
> be thread safe. Well in a C++ component XPCOM throws up
> some warnings if i don't the use:
>
> NS_IMPL_THREADSAFE_ISUPPORTS
>
> macro, like in the LDAPChannel implementation.
> I dunno much about the xpconnect stuff.
> I think your assumption is correct.
Well, that takes care of making sure that AddRef and Release are done
in a threadsafe manner, and xpconnect does ensure that level of
thread-safety. And JS itself (when compiled with multi-threading
support) probably provides more atomicity assurances (like getting and
setting vars). But what I was hoping Peter V. could comment on was
whether any of the complex datastructures in the datasource need any
extra thread-safety guards. My suspicion is that they're ok as is,
but I'd like to be sure...
> The existing abdirectory data source (nsDirectoryDataSource.cpp)
> does not 'exibit' this type of behaviour. This maybe one
> of the caveats i alluded to in the posted document.
> Methods on the nsIAbDirectory interface are sort of
> synchronous, but asynchronisty (yuk word, sounds like
> some anti-Jungian conspiracy!) is achieved through
> adding listeners to an address book session which
> propagates up calls to the RDF data source.
>
> I think for an initial implmentation of a personal LDAP
> address book it may not be as important as a corporate
> because there is likely to be less information (i.e. cards)
> returned, but then again it also depends on response
> time...
Yeah, hard to say. That seems unlikely to be workable for the
organizational address book of any size, as you say. There are
probably plenty of folks with personal address books of multiple
hundreds of cards, too. And it's worth remembering that blocking
at all on the UI thread is a serious no-no, since that will stall out
layout in all open mozilla windows. That's the reason that the
LDAP datasource is coded to run on the LDAP connection thread.
> I have written a read only perosonal LDAP address book
> (based on code from John) using the refactored framework
> and am able to copy cards from the LDAP to the local in
> the mozilla GUI.
> See attached for code.
> (this is still a bit of a hack still because the LDAP location
> is hardcoded and the bootstrap (or address book directory
> manager component explicitly instantiates this implementation
> because there is no creation/preferences functionality yet).
Cool; thanks for posting the code. Writing more comments as you go
would make it easier to read. :-)
> <brain-splurge>
> This will not work for corporate LDAP address books
> since there needs to be an associated query.
I'm not sure what you mean by this; can you elaborate?
> Since the corporate will be read only and will not support
> mail lists many of the methods on the nsIAbDirectory
> interface do not make sense. This implies that there maybe no
> point using this at all and we need a composite RDF directory
> data source able to operate on the existing and LDAP datasource.
While it's probably not anyone's priority to implement either of those
features for organizational addressbooks, neither of them is
non-sensical, and I can think of circumstances where both might be
useful. So I wouldn't go quite so far as to say "no point".
> I don't know much about the consequences of this with respect
> to changes in respective js code and xul.
Me either.
> About LDAP XPCOM usage:
> I am curious to know why a two stage operation process is
> used on queries. The first operation-listener listens on
> a bind and instantiates a new operation which performs
> the search.
This is done because LDAPv2 clients, as well as any authenticated
clients (not yet implemented) require a bind operation before doing
any other LDAP operation. There are plans to work on sharing LDAP
connections among clients, so if the wrapper already has a bound
connection, the bind operation will sometimes (in the future) just be
a no-op.
Dan
--
