Hi:No, I don't agree at all. Perhaps some LDAP implementations behave this way; however, it's simple to point your ldapsearch command towards an LDAP server that behaves differently (assuming of course you're running one somewhere, and that you know about it).Thanks for your replies. You both said pretty much the same thing - it can't
be done. I trust you will agree that when you create a record with
ldapmodify, the attributes are stored in the order you enter them, and when
you retrieve the record with ldapsearch, the record is returned with the
attributes in the original order.
So it's not a limitation of the LDAP protocol, it's just a question of why perldap doesn't do it.Wrong. Perldap is behaving according to the protocol. (See below.)
This feature would place perldap in direct violation of the LDAP protocol. To quote RFC2251 section 4.1.8:
I realize the ordering is completely immaterial to the operation of the LDAP
directory and therefore, this is not a high priority item for perldap
development, but it would be a nice feature.
Each attribute value is distinct in the set (no duplicates). The(Emphasis in original.)
order of attribute values within the vals set is undefined and
implementation-dependent, and MUST NOT be relied upon.
So you see, when we said that it can't be done, we weren't kidding.
And since the protocol forbids counting on the order or attaching an significance
to the order, you're asking for trouble if you start doing so. For example,
the next version of your server may suddenly change the order of its results,
without any warning, and be perfectly within its rights to do so.
Dave Kernen
The Kernen Group, Inc
