Dan Mosedale <[EMAIL PROTECTED]> writes:
>John Marmion <[EMAIL PROTECTED]> writes:
>>
>> No problem for me. I wanted to follow up on the meeting and
>> take this opportunity to clarify the Autocompletion (typedown)
>> functionality that you are hoping to add. As part of our
>> requirements to add LDAP access to the address book, we had also
>> looked at implementing autocompletion. There exists in the addrbook/src/
>> directory the nsAbAutoCompletion interface and as I understand it Paul's
>> proposal would make use of this. I want to find out if what you
>> are doing will go make use of this interface or is it something
>> completely different. Will we be able to leverage anything from the
>> work you are doing. I would be grateful if you could clarify this
>> for me. Thanks.
>
>Paul's proposal doesn't seem to mention the autocomplete except in
>passing, but it seems like it ought to (in theory) just continue to
>work after the refactoring, but with Mork addressbooks _and_ LDAP
>addressbooks.
>
In theory yes. I think it needs a little modification.
>However, I suspect that we're going to turn up parts of the existing
>code that depend on the fact that Mork returns will be very quick
>since they are completely local. One possibly relevant problem is
>that right now, the autocomplete menu has to be completely built at
>once, since it's not RDF data accessed through a XUL template. I
>kinda of suspect that forcing the LDAP stuff through the existing
>nsAbAutoCompleteSession code session is likely to accentuate that
>problem.**
>
Yep.
The autocomplete runs through all address directories
checking all cards. Not very efficient for remote
implementations and not a solution for corporate
LDAP address books with thousands of entries.
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.
>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.
>* 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.
One thing i am having touble understanding
is the relationship between the LDAP RDF datasource
and the nsIAbDirectory and nsIAbCard interfaces
and implementations of.
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?
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.
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.
We could use it internally for nsIAbDirectory
implementations but is this an unnecessary performance
hit?
>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. For the momenet the address book preference
code could ignore ldap types until the specific
interfaces implementations have been written?
Paul.
>Dan
>
>** 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.
>
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
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;
};
/*
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.
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.
