On 01/21/2013 04:48 PM, John Dennis wrote:
On 01/16/2013 10:45 AM, Jan Cholasta wrote:

this patch adds initial support for custom LDAP entry objects, as
described in <http://freeipa.org/page/V3/LDAP_code>.

Just in case you missed it, I added some requirements to the above
design page about making LDAP attributes and their values be "smarter".

It would be nice to discuss these changes on the list, since the implementation is already underway...

An LDAP attribute has a syntax defining how comparisons are to be
performed. Python code using standard Python operators, sorting
functions, etc. should "just work" because underneath the object is
aware of it's LDAP syntax.

The same holds true for attribute names, it should "just work" correctly
any place we touch an attribute name because it's an object implementing
the desired comparison and hashing behavior.

Thus the keys in an Entry dict would need to be a new class and the
values would need to be a new class as well. Simple strings do not give
rich enough semantic behavior (we shouldn't be providing this semantic
behavior every place in the code where we touch an attribute name or
value, rather it should just automatically work using standard Python

I think plain strings are fine for attribute names, as long as the entry class handles them correctly. We don't really need to hash or compare them outside of an entry. Or at least not enough to warrant a special class, IMO. Of course Entry.keys() and friends should return normalized names that would sort/hash correctly.

As for attribute values, you're right that LDAP specifies how they should be compared, but that's only in the context of a single attribute type. What happens when you try comparing a case-sensitive string to a case-insensitive one in Python?


Freeipa-devel mailing list

Reply via email to