Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

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 

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
 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
-- 

Re: Organisational and 10^3 address books

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
>   Wanted to run by some things i think are required
>   for the Mozilla address book to cater for organisational
>   (LDAP) and '10K' address books i.e. address books
>   with so many cards it is not feasible to list all cards.
>   
>   o Need attribute that defines if an address book
> is only searchable. This will define organisational
> address books.
> 
> - For 10k address books i think the user needs to
>   define this via a preference which states that
>   the address book should only be searched.

Makes sense. 

> - Is an attribute needed to define type so that
>   associated icons may be displayed?

Type of addressbook?  Or type of card?

>   o GUI Search functionality like netscape 4.X and
> the proposed search functionality that was
> described by Josh Harding and suggested by
> Matthew Thomas.

<[EMAIL PROTECTED]">news://news.mozilla.org/[EMAIL PROTECTED]> is 
what I assume you're referring to.

I agree; this seems like a nice GUI.

> When a searchable address book is selected
> the 'search bar' should be displayed.

I'm not quite sure what you mean by this.

>   o The RDF directory data source needs a query
> command that takes as an argument the search
> critera defined as a boolean expression tree.
> 
> - The data source will be responsible for 
>   for passing the search arguments to the query
>   interface on the RDF directory resource conponent
>   and listening to the results which are then
>   asserted. Thus it is asynchronous in operation.

So if I understand you correctly, this is really an optimization: that
is, a generic helper class could do the entire boolean expression
processing on _any_ RDF datasource.  But this allows datasources which
understand expressions themselves (eg LDAP) to do it much quicker.
Right?

>   The query command should unassert previously
>   returned cards.

Why is this necessary?  Won't the newly created listener not know
about any previously returned cards?

> - A general linear search query component is 
>   available for directories that do not support
>   the query interface. This means that existing
>   local address books may also be searched.

If this only exists to deal with the exist local addressbook, wouldn't 
it make more sense to simply write an instance of the query interface
for the local addressbook that does more clever stuff with
datastructures in order to avoid doing a linear search?  Note that I'm 
completely naive about how mork & the local address book work, so this 
may not be practical.

>   o Offline mode. For organisational address books
> it should be possible to create a local address
> book and copy the cards obtained from the search
> criteria. I don't think a local address book
> needs to be created or modified every time a
> search is performed like 4.X functionality,
> but i am not sure how offline works in general.

I _think_ these were two separate features in 4.x: persistent queries
and replicating addressbooks locally.  I'm not positive about this
though, perhaps someone who knows for sure can pipe up...

>   I think we have moved significantly forward to
>   enable the functionality to support this behaviour.
>   The only area I am unsure about is the GUI bit.

Yeah; I think things are definitely going in the right direction!
What specifically about the GUI are you unsure about?

Dan

-- 

Re: Organisational and 10^3 address books

[Josh Harding]

Paul Sandoz wrote:
> 
> Wanted to run by some things i think are required
> for the Mozilla address book to cater for organisational
> (LDAP) and '10K' address books i.e. address books
> with so many cards it is not feasible to list all cards.
> 
> o Need attribute that defines if an address book
>   is only searchable. This will define organisational
>   address books.

Is it possible to query the AB and see how many records are in there
before attempting to display?  If so, how about a pref (defaulting to
10K or whatever) that specifies the MAX_DISPLAY_RECORDS.  If the AB has
more than that number of records, it's search-only.  This would require
less interaction by the user.  They don't have to know to set a specific
AB as search-only... it's done automatically for large ABs, but the
advanced user still has the option of seeing all records if they really
want.

>   - Is an attribute needed to define type so that
> associated icons may be displayed?

You mean have a diff icon per AB that indicates if it can be browsed or
just searched?

> o Offline mode. For organisational address books
>   it should be possible to create a local address
>   book and copy the cards obtained from the search
>   criteria. I don't think a local address book
>   needs to be created or modified every time a
>   search is performed like 4.X functionality,
>   but i am not sure how offline works in general.

How about this:  After a search is completed (regardless of the source),
present the user with the option of merging the results into an existing
AB[1] or adding to a new one:

[Save these search results to]  [Personal AB:^]

In the select list, is a list of all local ABs and the keyword .

Scenario:  User selects and AB with >10K records and gets the search
options.  They perform a search for  contains "@".  Do you stop
the search after MAX_DISPLAY_RECORDS(see above) are found and present a
warning?

[1]: Merging search results could present other problems.  What do you
do with duplicate entries?  Options:

1) Overwrite the existing entry with the one from the search results.
2) Keep the old one and ignore the new one.
3) Use data from the new one to fill in blank fields from the old.
4) Present the user with a dialog giving them the above options and a
"use this choice for all remaining conflicts".

None of those seem real appealing to me.

The Amigo

Re: Perldap Attribute storage order

[David J Kernen]

Russell Wilton wrote:

> To say that this violates the protocol, implies that the ldapmodify
> and ldapsearch programs distributed with the Netscape LDAP also
> violate the protocol, since they maintain attribute order.

Sorry, but I still disagree. The ldapsearch  command is stream-oriented,
which is to say it writes to stdout as it pumps through the chain of
responses from the search. If Nectar's ldap server happens to return
values in FIFO order, then that's the way they happen to print them out.
I doubt that ldapsearch (and similarly but in an opposite direction,
ldapmodify) do anything special to maintain order; they just process
what they're given in the order they receive it because that's the
easiest way. RFC2251 doesn't require anybody to change the order just to
avoid the appearance of maintaining it.

I'm also not sure how useful it would be to control the order; I've been
doing ldap programming about eight years and it's never been something
that I wanted to do. Examining access logs and the changelog have always
been sufficient for me, along with the occasional ldif diff.

Nevertheless, you seem to understand that no special meaning should be
attached to the order in which attribute values are returned and still
want to manage it anyway, so by all means go ahead and do so. You don't
need any changes to perldap; changes to your script(s) are all that's
required. Just use the addValue method instead of setValues to add one
attribute/value pair per method call, and then call the update method
after calling addValue. That will do what you want. Under the covers, it
will be slightly different from ldapmodify, since instead of one modify
operation you'll do one per attribute/value pair. But you'll have
complete control over the order in which updates are applied to the
directory.


Dave Kernen

Re: Perldap Attribute storage order

[Russell Wilton]

David J Kernen wrote:

> I doubt that ldapsearch (and similarly but in an opposite direction,
> ldapmodify) do anything special to maintain order; they just process
> what they're given in the order they receive it because that's the
> easiest way.

That's all I wanted Perldap to do too.  Just process them in the order it
receives them.  I'm pretty sure that Perldap does do that on reading, just
not on writing.  Unfortunately, Perl hashes don't maintain any order, so for
Perldap, it's NOT the easiest way.  I guess nobody but me thinks it's worth
the trouble to work around that.

> I'm also not sure how useful it would be to control the order; I've been
> doing ldap programming about eight years and it's never been something
> that I wanted to do. Examining access logs and the changelog have always
> been sufficient for me, along with the occasional ldif diff.

When I'm debugging a problem, I just want to be able to use ldapsearch to
examine records and have them displayed in a more reasonable order, ie., the
order I stored them in.

> Just use the addValue method instead of setValues to add one
> attribute/value pair per method call, and then call the update method
> after calling addValue. That will do what you want.

I think the overhead of adding one attribute at a time would be more than
it's worth.  I guess the solution for me is to write a replacement for
ldapsearch that displays records with the attributes in the order I want to
see them.

Thanks again for your time.

Russ

--
Russell D. Wilton E Mail: [EMAIL PROTECTED]
Network Services Manager  Voice:   (403) 329-2525
University of Lethbridge  FAX: (403) 382-7108
4401 University Drive   Lethbridge, Alberta, CANADA   T1K 3M4

Perldap and closing connections

[Mark Reynolds]

Hello all,

I've been having a hard time trying to find out how to close a
connection properly in perldap.

I have seen references to conn->close()

Many examples do not even include this.  Also should there be a unbind?

Thanks in advance,

Mark


begin:vcard 
n:Reynolds;Mark Reynolds
x-mozilla-html:FALSE
org:Directory and Security Sustained Engineering;Sun | Netscape Alliance
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Product Support Engineer
fn:Mark Reynolds
end:vcard

perldap and closing connections

[Mark Reynolds]

Hello all,

I've been having a hard time trying to find out how to close a
connection properly in perldap.

I have seen references to conn->close()

Many examples do not even include this.  Also should there be a unbind?

Thanks in advance,

Mark

Re: Perldap Attribute storage order

[Leif Hedstrom]

Russell Wilton wrote:

> David J Kernen wrote:
>
> > I doubt that ldapsearch (and similarly but in an opposite direction,
> > ldapmodify) do anything special to maintain order; they just process
> > what they're given in the order they receive it because that's the
> > easiest way.
>
> That's all I wanted Perldap to do too.  Just process them in the order it
> receives them.  I'm pretty sure that Perldap does do that on reading, just
> not on writing.  Unfortunately, Perl hashes don't maintain any order, so for
> Perldap, it's NOT the easiest way.  I guess nobody but me thinks it's worth
> the trouble to work around that.

I'm gonna go through all old perldap bugs, and new bugs, and use this for a
v2.0 PerLDAP "plan"... I'll add the request above as an RFE for v2.0, it's the
best we can do for now (I don't have the time for doing more work on
PerLDAP v1.4).

Also, if there are people out there who'd like to contribute to PerLDAP, please
step up. I'm really sorry that development of PerLDAP has grinded to a halt,
but sometimes real life just sucks you in... I still think we can make a
PerLDAP v2.0 that kicks ass, I have some major changes going in, like switching
to async I/O, totally change argument passing etc.. This will allow us to use
new LDAP v3 features as well, like controls.

Cheers!

-- leif

Re: Organisational and 10^3 address books

[Dan Mosedale]

[EMAIL PROTECTED] (Josh Harding) writes:
> Paul Sandoz wrote:
> > 
> > Wanted to run by some things i think are required
> > for the Mozilla address book to cater for organisational
> > (LDAP) and '10K' address books i.e. address books
> > with so many cards it is not feasible to list all cards.
> > 
> > o Need attribute that defines if an address book
> >   is only searchable. This will define organisational
> >   address books.
> 
> Is it possible to query the AB and see how many records are in there
> before attempting to display?  If so, how about a pref (defaulting to
> 10K or whatever) that specifies the MAX_DISPLAY_RECORDS.  If the AB has
> more than that number of records, it's search-only.  This would require
> less interaction by the user.  They don't have to know to set a specific
> AB as search-only... it's done automatically for large ABs, but the
> advanced user still has the option of seeing all records if they really
> want.

In LDAP, anyway, you can't know this without actually doing a query
and hitting the limit.

> > o Offline mode. For organisational address books
> >   it should be possible to create a local address
> >   book and copy the cards obtained from the search
> >   criteria. I don't think a local address book
> >   needs to be created or modified every time a
> >   search is performed like 4.X functionality,
> >   but i am not sure how offline works in general.
> 
> How about this:  After a search is completed (regardless of the source),
> present the user with the option of merging the results into an existing
> AB[1] or adding to a new one:
> 
> [Save these search results to]  [Personal AB:^]
> 
> In the select list, is a list of all local ABs and the keyword .

This sounds cool!

> Scenario:  User selects and AB with >10K records and gets the search
> options.  They perform a search for  contains "@".  Do you stop
> the search after MAX_DISPLAY_RECORDS(see above) are found and present a
> warning?

In LDAP, at least, we probably need to set some minimum limits so that
naive users don't drive the server into the ground with enormous
searches.  Perhaps a minimum search term of at least 2 or 3 characters
would be a good such limit.

> [1]: Merging search results could present other problems.  What do you
> do with duplicate entries?  Options:
> 
> 1) Overwrite the existing entry with the one from the search results.
> 2) Keep the old one and ignore the new one.
> 3) Use data from the new one to fill in blank fields from the old.
> 4) Present the user with a dialog giving them the above options and a
> "use this choice for all remaining conflicts".
> 
> None of those seem real appealing to me.

Probably number 4 is the only one that's really workable.

Dan

-- 

nsuniqueID equivalent in 4.1x DS?

[supernot]

I know that there is a guaranteed unique object-level attribute on iPlanet
5.0b Directory Server, called nsuniqueid.  I have found this easy to query
for using LDAP.

However, I haven't been able to find an equivalent guaranteed unique
attribute
on the Netscape/iPlanet 4.1x DSes.  Does anyone know if there is an attribute
of this type used on the 4.1x servers?

BTW, I am aware of, but not referring to, the uid uniqueness plug-in.  This
doesn't really fit the bill, unfortunately.

Thanks for any help you can offer!





 -  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]