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
