Dan Mosedale <[EMAIL PROTECTED]> writes:
>> 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?
>
The existing nsDirectoryDataSource defined
as rdf:addressdirectory
>> 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.
>
Thanks for useful comments.
>> 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.
>
Sounds interesting.
>> *
>> */
>> 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".
>
No its not about sorting its about how an item would be
compared (or 'matched') against an instance.
e.g. Match 'first name' which CONTAINS 'paul'
Match 'email' with REGEXP '^d.*@.*\.org$'
Match <property name> <match<Type?>> <property value>
I originally called it 'matchType', changed it, changed it back
and re-changed it! Basically i am not sure.
>> /**
>> * 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.
>
Good idea.
>> interface nsIAbDirectoryQuery
>> {
>> // ? Do we need supported match
>> // ? types
>
>It seems like it; this is something that folks might want to specify
>via a preference.
>
Hmm.. maybe its more to do with what an implemention
supports e.g. some implemetations may not support
regexp match so its not a user 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?
>
I was thinking that the query interface could be used to
get child cards in an asynchronous manner, we know
when all have been received because the query result
will tell us. This is a response to the fact the the
nsIAbDirectory.getChildCards could be implemented
asychronously notifying RDF indirectly making it
impossible to know when all the cards have been
recieved.
>> /**
>> * 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
>
Yep. Ah!, i would also like the possibility to return
other types like nsIAbCard.
Hmm... perhaps two methods are required. One for strings
and the other for more detailed information using the
nsIProperties interface.
>> * @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?
>
Not sure i understand. I think that:
_
"max number of hits to return" = resultLimit
i.e. i don't understand the difference.
>> 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.
>
Just had a thought; some context may be required
if multiple queries are performed using the same
listener object.
Thanks,
Paul.
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
