On 01/22/2013 08:31 AM, Jan Cholasta wrote:
On 21.1.2013 17:46, Petr Viktorin wrote:
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?

I would say TypeError. But I don't think we should be too strict in
following the schema, it's too much work for questionable benefit. As
you pointed out, it might bring problems for which there is no right

Well, instead of "compares equal" you can say "have same hash":

If you make "abc" == Insensitive("abc") == "ABC", then "abc" and "ABC" must hash the same, which they don't.

If you make "abc" != Insensitive("abc") != "ABC", then I can't say entry["abc"].


Freeipa-devel mailing list

Reply via email to