Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> >> <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
Which RDF datasource do you mean?
> 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.
Cool; comments below.
> >> 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...
Well, the idea is to bring back nsLDAPService from the dead (it's
currently old unused code). Whenever you need a connection, you'll
pass the service a tuple of (servername, port, bindname, passwd) or
somesuch, and then it will either create the connection for you and
hand it back, or else just hand back an existing connection. After a
connection has been idle (ie noone is holding a strong ref to it) for
a while (5 minutes or so?), the service will cause it to be shut
down. Perhaps the service should do the bind for the caller, I'm not
entirely sure. It may depend on what sort of rebinding support we
need to provide. Leif is going to be looking at this, so he may be
able to give you more insight here.
> interface nsIAbDirectoryQueryMatchItem
> {
> /**
> * The type of match
> * contains, does not contain
> * is, is not
> * begins with, ends with
> * sounds like (?)
Sounds like seems like a good idea, since LDAP servers do support it.
Leif, do you know of other interesting stuff that LDAP supports that
might be worth making available here?
> *
> */
> attribute long match;
So is this attribute necessary because you need to know how to sort
the list of returned matches? It seems like it would be a bit clearer
to call this "type" or "matchType".
> /**
> * The match value
> *
> * ? Should this be nsISupports
> * ? If so how do we represent
> * ? wstring values
> */
> attribute wstring matchValue;
> };
Using a string seems reasonable to me. After all, if you need the
object that implements this interface to provide you with some other
interface, you can always QI to that second iface.
> interface nsIAbDirectoryQuery
> {
> // ? Do we need supported match
> // ? types
It seems like it; this is something that folks might want to specify
via a preference.
> // ? Do we need a parameter to control
> // ? how sub-directories are queried
I guess that depends on the UI you wish to provide. Is there some
case where you might not want sub directories searched?
> /**
> * Initiates a query on a directory and
> * sub-directories for properties on cards
> *
> * @param matchProperties
> * The properties and values to match
> * Value could of type nsIAbDirectoryQueryMatchItem
> * for matches other than ?contains?
> * @param matchItems
> * Defines how multiple match items should
> * be treated for a query result
> * Match one or more
> * Match all
> * @param returnProperties
> * The properties that will be returned that
> * result in a query result
> * ? Can this be represented as an array of strings
> * ? instead
Yes, it can. And it would be nicer to folks accessing this interfaces
from languages other than C++. An example of how to do it is at
http://lxr.mozilla.org/seamonkey/source/xpcom/threads/nsIProcess.idl
> * @param nsIAbDirectoryQueryResultListener
> * The listener which will obtain individual
> * query results
> * @param resultLimit
> * No more than 'limit' results will be returned
> */
> void doQuery (in nsIProperties searchProperties,
> in long matchItems,
> in nsISupportsArray returnProperties,
> in nsIAbDirectoryQueryResultListener,
> in long resultLimit);
> };
>
Should there be a "max number of hits to return" parameter here too?
> interface nsIAbDirectoryQueryResultListener
> {
> /**
> * Called when a match is found. May be
> * called from a different thread to the
> * one that initiates the query
> *
> * @param result
> * A individual result associated returned
> * from a query
> */
> void onQueryItem (in nsIAbDirectoryQueryResult result);
> };
>
> interface nsIAbDirectoryQueryResult
> {
> // ? Do we need to have the attributes
> // ? associated with the query here
> // ? i.e. parameters passed on the doQuery method
I suspect that the answer to this will become more clear as you get
deeper into the coding.
> /**
> * The type of result
> * query match
> * query finished
> * query error
> *
> * Identifies a query entry, the query has finished
> * or that an error has occured
> */
> readonly attribute long type;
>
> /**
> * The result of a singular match for a card
> *
> * Only valid when the attribute type is
> * of 'query match'
> */
> readonly attribute nsIProperties result;
> };
Dan
--
