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.
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.**
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.
* 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.
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?
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.
