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?
I think I have already answered this question. Yes we should show the result
of the search in local addressbook without to have to wait on LDAP which
could be very slow. For that we need to have only on autocomplete session
which implement several directory search simultaneous. Some LDAP are faster
than other therefore we should proceed them in parallel and not in serial.
* 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"
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 directori!
es
*/
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?
Right, if you need new stuff, we just need to extend the current interface.
But remember, this interface is generic. It's for any kind of autocomplete
like URL or email address