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

Re: Supported RFC's and "features"

Clowser, Jeff (Contractor) wrote: 
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).

OpenLDAP stands out in a lot of ways - it actually implements the X.500 data model as mandated by the LDAP spec, it actually performs well, it actually stores your data and returns the same values you stored without corrupting or losing them. These are traits that none of those other vendors offer, nor can these features easily be added to those other offerings.

On the flip side, we can easily add an overlay to OpenLDAP to provide SSS/VLV. It would satisfy a checklist, but it probably still wouldn't prevent client apps from misbehaving, since the actual specs are so full of holes and there are so many undefined behaviors to deal with.

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

Since the specs fall down in so many cases, you still need to write code to compensate for those failures. All this does is make more work for the developers. I guess if those folks are being paid by lines-of-code it makes sense for them...

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...)

Any apps using SSS/VLV were already broken, before OpenLDAP entered the picture. Very likely they have already failed in the field, but nobody noticed the data inconsistencies caused by those failures. It's only a matter of time before they're going to be forced to be rewritten anyway. (E.g., an AD DIT has multiple partitions all glued together by referrals. SSS doesn't do anything special with referrals; the client has to figure out what to do anyway.)

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 :)


Indeed.
--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/