[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Supported RFC's and "features"

>Howard Chu <hyc@symas.com> writes:
>> I suppose we need to update our published roadmap. I don't consider
>> or VLV to be particularly important or well-designed features. In
>> OpenLDAP has an RFC-compliant implementation of SSS which is a pure
>> no-op; this is perfectly compliant because the SSS spec is so utterly
>> useless in real directories. Since VLV requires SSS, it is IMO
>> useless or at least seriously flawed, and I have a strong aversion to
>> implementing flawed designs. (Never mind all the other flawed designs
>> we're forced to live with already...)
>It might be worth noting that, depending on your application and the
>provenance of the data, the valsort overlay may actually be what you
>rather than server-side sorting.
>Russ Allbery (rra@stanford.edu)

As I read the man page, valsort sorts *values* of an attribute within an
entry.  SSS sorts the order *entries* are returned, based on the
(presumably single) value in some attribute(s).

While I agree with what people are saying about the negatives of SSS and
poor design (such as how do you sort using a multivalued attribute as a
key [which val do you use?] -  it generally expects attributes to have a
single value or only uses the "first" value [which in and of itself is
undefined for most (all?) attribute types], and the rfc doesn't even
touch on this), the problems I face are:

1.  Most other LDAP server choices implement it (I think Sun/Red Hat,
Microsoft, Novell, Oracle, etc all support this control, so OpenLDAP
stands out by not having it).

2.  Since it's so commonly implemented, developers tend to expect it to
be there, and write code that uses/depends on it.

So... I'm kinda stuck with it as a requirement, and justifying why
people have to rewrite apps (or in the case of COTS apps, possibly
breaking them with no option to fix/rewrite) becomes a pretty hard sell.
(And yes, any app that actually *breaks* because it didn't check that an
optional control isn't there is itself broken, but the world is what it
is, and I don't make all the buying decisions...)

In any case, whatever the reason, OpenLDAP doesn't implement it - it is
what it is, and I don't fault it - I just have to identify it as not
meeting one of many requirements.  How important that requirement is in
the overall picture is yet to be seen.  If there were any solutions that
met everyones requirements, we wouldn't have to do evaluations :)

 - Jeff