Hi Dan and Paul,
You should explain to me what your question about threadsafety is,
because I haven't followed the discussion really closely. The datasource
currently waits till the last entry is in before asserting every result
as a child of the search URI. The reason it currently does that is
because I had a bug where the results didn't show up at all, and I
thought it was caused by the fact that the delegate "messagelist" didn't
have all the entries yet that the datasource asserted. But it turned out
to be a missing QI somewhere. I haven't removed the workaround logic
yet, but I'll try to do that and see if that causes any trouble. The
assertion on every attribute when the messages come back could probably
also be removed. It seemed like a good idea at the time, but I've
learned since then and with many search results and lot's of attributes,
this will cause the RDF code to assert for hours eventually ;-). So I'll
try to fix those two things, and comment the code more (as I promised
Dan for a while now).
Hope this helps,
Peter
Paul Sandoz wrote:
> Dan Mosedale <[EMAIL PROTECTED]> writes:
>
>>>> 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...
>>
>
>
> Yes.
>
>
>>> 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.
>>
>
>
> Quantity of cards:
> Yes, that is true.
>
> Blocking: see below
>
>
>>> 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. :-)
>>
>
>
> Ha, old habits die dard, point taken though.
>
> Ermm... given what you have said about blocking
> i think this does the no-no and blocks the UI
> thread; the enumeration returned will wait until
> data is avaliable and this causes the UI thread
> to block. Damn!
>
> However there is a way around this because the
> RDF data source listens on nsIAddrBookSession
> and the resources send calls to this when new
> items have been created. This results in OnChange
> OnAssert and OnUnassert calls on RDF observers
> depending on the parameters.
>
> It is interesting that the js data source asserts
> message properties on the recieving message resource
> but only asserts the child property on the parent
> resource for all messages at the end of a search
> query.
> Does this mean that, although the UI thread will not
> block, the UI with the example.xul in the xpcom/tests
> directory will not update with new tree items until
> the search is complete?
>
>
>
>
>>> <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?
>>
>
>
> A picture is worth a 1000 words?
> See attached.
> i.e. 4.x functionality.
>
> Hence the need for a query interface which
> is able to return an enumeration of cards
> (or perhaps URIs) or notify the RDF datasource
> via the address book session from a doQuery
> command on the data source.
>
> It is more complicated than the auto completion
> but could be used for auto completion.
> Attached is a new revision of the query intefaces.
>
>
>
>>> 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".
>>
>
>
> Agreed.
>
>
>
>>> 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.
>>
>
>
> Ok.
> I was wondering about the management of connections
> and how 'pools' connections could be reused efficiently...
>
> Paul.
>
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x19219
> +353-1-8199219
>
>
