Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> The initial idea was to unify autocomplete and
> and connection to LDAP address books (corporate and personal)
> though a query interface on the directory components.
> A doQuery method on this interface would return an
> enumeration of results, limited by a maximum (which
> may be different for autocomplete and viewing a table
> of addresses). The autcomplete component could then
> check if the directory supports the query interface
> and use this instead of obtaining each card.
> Not sure if this is the best way. I have tended to think
> in terms of interfaces and components instead of RDF data
> sources (more on this later). Some notes on this idea
> are attached.
> This also should allow for efficient autocomplete on
> other address book types, like outlook.
>
> Dan Mosedale <[EMAIL PROTECTED]> writes:
> >
> >Additionally, Netscape management is very keen on seeing basic
> >autocompletion work done by Mozilla 0.9, which is quite soon
> >(~March 14th). So I've concocted following strategy to that end:
> >
> >* write an nsLDAPAbAutoCompleteSession class, probably implementing from
> >nsIAbAutoCompleteSession to do the LDAP work.
> >
>
> This, presumably, would kick of a search on all
> LDAP address books that a user has set up.
> i.e. would query the top level directory and obtained
> a list of sub-directories with the approriate LDAP
> addressbook scheme and use the URI (replace the addressbook
> scehme with ldap:) on the RDF resource, or go directly though
> the preferences.
It seems like it would be easier to code, though conceivably slightly
slower, if each LDAP address book were treated as a separate
autocomplete session to be composited. Jean-Francois, any thoughts on this?
> >* write an nsICompositeAutoCompleteSession interface and a class that
> >implements it to allow the compose window to run multiple complete
> >sessions at once with the stuff in the local addressbooks taking
> >precedence over stuff in LDAP.
> >
> >* at some point after that consider moving towards a more general RDF
> >solution, as outlined in the footnote below.
> >
>
> Yes. We have been thinking about the relationship
> between how data is obtained and how it is 'pumped'
> through to XUL. To wait until all data is obtained
> before returned, as you point out, is not good.
Yeah, I should actually give Jean-Francois Ducarroz credit for
pointing out this particular issue to me. :-)
> One thing i am having touble understanding
> is the relationship between the LDAP RDF datasource
> and the nsIAbDirectory and nsIAbCard interfaces
> and implementations of.
Thus far, I've been mostly focussing on the autocomplete stuff and so
unfortunately don't have as good of a handle on the rest of the
addressbook. Perhaps Candice Huang, whom I've CCed on this note, can
comment a little more on the use of RDF inside the addressbook code
and what directions she thinks might work...
> 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?
> I am in a bit of a dimlemma as to whether this
> is the correct way to go forward. The refactoring
> certianly makes it easier for *us* to implement new
> address sources and to allow for a singular star SDBC
> component to use the general interfaces in the
> knowledge it only has to use RDF resources and
> no RDF datasources.
I'd be interested in hearing Candice's comments on this. Candice?
> However alot of the work/smarts has already
> been done in the js LDAP datasource. But this
> is general and not address specific and perhaps
> address semantics should not impose on this at all.
> Somthing extra would then need to map the appropriate
> information.
I assume that the only extra address book semantics necessary in the
datasource would be a table of the attributes in the NC-rdf namespace
that the addressbook uses and how they should be mapped from the
corresponding inetOrgPerson attributes from the LDAPATTR-rdf
namespace. Is that true? If so, that seems really lightweight and
straightforward, so I don't have any particular problem with putting
that in the datasource.
> We could use it internally for nsIAbDirectory
> implementations but is this an unnecessary performance
> hit?
Possibly. The RDF engine itself is not fast under all circumstances,
and the performance characteristics of the LDAP RDF datasource are
currently unknown. The LDAP nsIChannel implementation in the XPCOM
wrapper is already running afoul of Mozilla's lack of prioritization
in the event-handling system (bug 50104), and it's certainly possible
that other LDAP-related code is going to hit the same problem. I
don't know whether using RDF would make that problem more likely to
show up or not. Though I sure hope 50104 gets fixed by 0.9, as it's
currently slated to.
> >So I think the answer is that you might be able to leverage off part
> >of this short term solution (the compositing of autocomplete sessions),
> >but that the Right Thing (moving to RDF) is likely to give you more
> >leverage.
> >
> >Comments? Thoughts? Suggestions?
> >
>
> I think the move RDF for autocomplete data
> makes sense.
>
> Given the time scale your prelimirary solution
> sounds good.
>
> How much would netscape like done by the 14th?
> because autcompletion will use the preferences
> (diretory or indirectly) of address books which
> are ldap servers which need to be created by
> users. I guess Csaba could help/advise here with his
> work.
<http://http://www.mozilla.org/mailnews/specs/proposals/LDAPAddressingPrefs.html>
has the prefs proposal that we've been discussing with Csaba.
Currently, we've got the autocomplete preferences only depending on
the directory server prefs (upon which the ldap address book prefs
would also depend). Any opinion on this?
> For the momenet the address book preference
> code could ignore ldap types until the specific
> interfaces implementations have been written?
Sounds fine.
> >** Note that the autocomplete stuff is written in XBL, and at this
> >moment, XBL and XUL templates don't play nicely together. Waterson
> >has been working on a fix for this (bug 39054), and once it gets
> >relanded in the tree (there was an aborted landing attempt last
> >night), it may then be reasonable to change the autocomplete
> >interfaces to use RDF for their data, which would allow RDF
> >assert()ing new entries into the menu as they arrive, as well as
> >perhaps obviating the need for the nsIAutoCompleteResults.idl
> >interface.
>
> [...]
>
>
> Auto completion uses the nsIAbAutoCompletionSession.idl
> interface which inherits from nsIAutoCompleteSession.idl
>
> A component in the address book implementas the former
> interface and is defined with the contract id:
>
> @mozilla.org/autocompleteSession;1?type=addrbook
>
> In the:
>
> mailnews/compose/resources/content/addressingWidgetOverlay.xul
>
> file there is a text field which has autocompletion set to
> true and defines the search type as 'addrbook'.
>
> <textfield id="msgRecipient#1" flex="1"
> class="plain textfield-addressingWidget"
> style="width:0px;" allowevents="true"
> onkeypress="awRecipientKeyPress(event, this)"
> autocomplete="true" timeout="300"
> searchSessionType="addrbook" displayMenu="true"/>
> </treecell>
>
> thus the xul will create the contract id for the auto-
> complete session from the 'searchSessionType' string
> and will obtain the address book autocomplete service.
>
>
> We need to ensure that this autocompletion service
> can work efficiently accross multiple address book
> types. Therefore we need some extra interfaces.
>
>
>
>
> /*
> Queries for cards over this directory
> and sub directories
> */
> interface nsIAbDirectoryQuery
> {
> void doQuery (wstring searchString
> in nsIAbDirectoryQueryListener
> in long limit);
> };
>
>
>
> typedef long AbDirectoryQueryStatus;
>
> interface nsIAbDirectoryQueryStatus
> {
> const long failed = -1;
> const long noMatch = 0;
> const long matchFound = 1;
> };
Why define a separate interface here rather than just using the
existing nsIAutoCompleteStatus?
> /*
> Listener for obtaining results
> from a query
> */
> interface nsIAbDirectoryQueryListener
> {
> void onQueryComplete(in nsIAbDirectoryQueryResults result,
> in AbDirectoryQueryStatus status);
> };
>
>
> /*
> Results returned from a query
> */
> interface nsIAbDirectoryQueryResults
> {
> readonly attribute wstring searchString;
> readonly attribute long limit;
> readonly attribute nsISupportsArray items;
> };
>
>
> This is very simple in that only a search string
> is taken as input, which corresponds to the same
> search string which is used in the autocompletion
> and the 4.x query. Results returned will be RDF
> resource card components.
>
> This will be adequate to support autocompletion
> and LDAP query to obtain a list of cards. However
> its not very efficient. Perahps we should be able
> to choose the type of result returned. For example
> for autocompletion it is not necessary to return
> the RDF resource, only the email address is required.
Jean-Francois, do you have comments on this?
> Given most of the use cases for address book query i
> don't think it is worth going for a general query based
> interfaces. The only use case where a general query
> would be useful for efficiency is with the SDBC driver,
> however i do not think this is a priority.
I tend to agree that generalizing it would be nice, but not a
priority. If that does get done at some point, though, the prefs
panels would have to change from what's in the current proposal.
Dan
--
