Wrong. Perldap is behaving according to the protocol. (See below.)I agree. Perldap is not required to return the attributes in any particular order.
This feature would place perldap in direct violation of the LDAP protocol.Here I disagree with you. As the RFC says, the order of attribute values is implementation-dependent, ie, Perldap can return them in any order it likes. Returning the attributes in the same order they were entered is one possible order and there is no reason Perldap couldn't use that order. 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.
To quote RFC2251 section 4.1.8:I understand that Perldap is at the mercy of the LDAP directory implementation. The directory is not obliged to return the attributes in the order they were entered and if it doesn't, there is nothing Perldap can do about it. If, however, the LDAP directory does return them in order, as the Netscape LDAP does, it would be nice if Perldap maintained that order.Each attribute value is distinct in the set (no duplicates). The
order of attribute values within the vals set is undefined and
implementation-dependent, and MUST NOT be relied upon.
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.I fully agree with you here. In my previous post, I indicated that this feature would be nice when scanning LDAP entries by eye. It's easier to find errors if the data comes back in the same order you put it in. But, I certainly wouldn't write a program that depended on that order.
When I program, I try to keep in mind the "principle of least astonishment". One application of that principle is that data shouldn't change when you aren't looking at it. When you put data in a file or a database, it's not unreasonable to expect to be able to get it back out again looking the same as it went in. Admittedly, the data can get reordered if you edit the record, but barring edits, it seems to me to be good practice for a database to return records the same way it receives them.
The developers of the Netscape LDAP directory would seem to agree with me on this one, since their implementation does maintain the attribute order. And the Perldap developer(s) have gone to considerable effort to maintain the attribute order internal to the perl part of Perldap as well. It just looks to me that they dropped the ball when passing the data to the C API part of Perldap. A fix would be nice, but certainly not necessary, for Perldap to continue to be a very useful package.
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
