[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-devel
Subject:    Re: Dynamic syntax support vs. slapo-constraint vs. schema declaration
From:       Howard Chu <hyc () symas ! com>
Date:       2007-11-27 15:16:24
Message-ID: 474C34C8.2000902 () symas ! com
[Download RAW message or body]

Michael Ströder wrote:
> Howard Chu wrote:
>> On the whole it doesn't seem like new syntaxes pop up in LDAP specs very
>> often. Some may say this is because they're not really needed. I believe
>> they've been sorely needed, and people have just avoided them because
>> they required too much work to properly support in existing
>> implementations. We can fix that.
> 
> This topic is somehwat interesting. I've banged my head against the wall
> several times when implementing schema support in web2ldap. The big
> question was where to draw the line between handling syntaxes and
> special attribute types, especially when having to override incorrect
> schema information retrieved from the server.

Overriding the server? That doesn't sound good...

> I have no strong opinion just some thoughts regarding how to dynamically
> make use of it at the client side:

> Something like (an improved) slapo-constraint will cover most cases for
> which one might also consider a syntax, e.g. limited set of option
> values for implementing the typical select lists. Or a certain string
> format etc.
> AFAIK slapo-constraint shipped in RE24 only supports regex checking
> defined in slapd.conf.
> Dynamic option value/description lists could be easily defined by
> defining an LDAP URL which searches the option values. IIRC someone is
> already working in this direction to improve slapo-constraint. (A base
> class for this is in web2ldap's plugin API now). But currently the
> client cannot query the constraints and adjust the UI accordingly in a
> vendor independent way. The client could read cn=config if back-config
> is deployed though.

Right, slapo-constraint is fine if you just need a constrained form of a 
string or text-based value. It's no help for more complex data types, like 
ASN.1 structures or multimedia objects (images, audio clips, etc.).

I suppose it's debatable whether it's a good idea to store a lot of these 
things in a directory. But in a lot of ways, it's better than storing 
somewhere else. E.g., an embedded address book in a cellphone stores contact 
info along with an image of the person and a custom ringtone. In the past 
we've recommended that directories only store references (URLs) to these other 
blobs, but that makes deployment and management much harder. Use LDAP for 
everything and you only need one protocol for syncing the cellphone to a main 
directory. (Of course, OpenLDAP has been embedded in cellphones before, but 
with open architectures like Google is pushing out with Android now, it 
becomes even more interesting.) On the flip side, it may be OK to just declare 
things to be blobs (octetString) in LDAP and let the application worry about 
figuring out what it really is. But that requires a lot of specialized parsing 
intelligence to be present redundantly in every application, instead of just a 
single generalized parser. It works, most apps today get along fine, but it's 
wasteful.

> A separate syntaxes is only needed if there's a strong need for distinct
> matching rules or normalization etc. Also a client has to implement the
> syntax. IMO this is the reason for spec authors to avoid syntaxes.

Yes, this was always one of the hassles of setting up X.500 clients. But I 
think it's unavoidable if you want everything to integrate properly. One of 
the reasons for exploring the route of implementing dynamic syntaxes in a 
language like Forth is that you can have a complete Forth implementation in 
only 30K or less of object code. We can bundle it under libldap and use it 
uniformly from both slapd and from clients.

> So I'm thinking about whether it would be worth to extend the subschema
> declaration of attribute types to define additional constraints. A
> client could interpret this and act accordingly. Well, a long way to go
> through standardization off course...
> 
> Any thoughts?

Constraints are only a partial solution. It's not worth it (to me) to go 
through all of that standardization effort for less than a complete solution.
-- 
   -- 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/
[prev in list] [next in list] [prev in thread] [next in thread]