Paul Sandoz <[EMAIL PROTECTED]> writes:
> >> Attached is the latest query stuff with boolean
> >> stuff combined. The existing directory query
> >> not inherits from the nsIBooleanExpression interface
> >> and the nsIAbDirectoryQueryArguments has a
> >> nsIBooleanExpression attribute.
> >
> >Why have nsIBooleanExpression and nsIBooleanCondition as empty
> >interfaces, rather than just passing an nsISupports there?
> >
>
> I guess i wanted to be explicit about the
> relationships between expression, condition
> and operation.
>
> Also the nsIAbDirectoryQueryArguments 'expression'
> attribute is explicit about what type it is.
>
> Do you think this is design overkill?
> i.e. document clearly instead.
I guess I'd vote for the documentation choice, rather than adding
extra interfaces, since those aren't completely free.
> >> I have been thinking about implementing asynchronous
> >> query for LDAP (personal and organsizational), just
> >> got to read up on LDAP filters so i can correctly
> >> generate from the simple boolean expression.
> >
> >I've been sorting out the best way to parameterize the autocomplete
> >code, and I suspect it'll be with filters as well. Maybe we need an
> >nsIFilter object.
> >
>
> Hmmm... do you mean an nsILDAPFilter object?
>
> Not sure how this would be different from a
> boolean expression tree i.e. an LDAP filter
> string (RFC 2254) can be generated from the
> expression, unless of course this interface
> will perform this conversion?
Well, my original thinking was of using ldap_create_filter()**
configuration syntax as a way to parameterize the autocomplete stuff
so that a single string would represent both the search filter itself
as well as the format of the autocompletion string. But now I think I
was just confused.
** see <http://docs.iplanet.com/docs/manuals/dirsdk/csdk41/html/filter.htm>
What I'll actually probably do is just go with two separate strings
for this, like was done in 4.x.
> I think gives the developer flexibilty if
> ldap attributes can be represetned as strings
> with helper interfaces which can convert from
> more abstract representations.
It still may have some value in the future for exactly this reason.
> In relation to filters and searches:
> I notice that URL search has been removed from
> the nsILDAPOperation interface. I think
> i remember reading why some time ago but
> its lost on me now....
Because it was just a wrapper for ldap_url_search(), which claims to
be async, but under the covers it's really not. See
<http://bugzilla.mozilla.org/show_bug.cgi?id=44017> for details.
> I think as long as the nsILDAPUrl is fully
> featured it does not matter because the
> appropriate parameters for the searchExt
> method could be obtained from this interface.
Right, this was exactly the thinking here.
Dan
--
