RE: Syntax functions in client library?

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo
> Masarati

> Steve Sonntag wrote:
> >
> > I assume you are describing the schema parsing functions
> > from ldap_schema.h?
> >
> > If that is the case the problem I see is that the client has
> > no idea what server the schema is being parsed for.  There
> > could be multiple connections, each server having perhaps
> > a slightly different schema.  Which one should be used
> > for enforcement?

> Good point.  That's another reason for having as much syntax
> handling functions available at the client side as possible/
> convenient.  I'm maintaining a "smart" (ah, ah, ...) client
> that populates a DS which started with 1.2.X and grew up with
> 2.0.X; I faced many syntax issues mostly in a naive way as soon
> as they came up but now I'd like to turn in into a really smart
> (as much as I can, of course ;) client by making it check the
> schema at the server level, yes, by using the ldap_schema.h
> stuff.  But, as soon as I know the syntax of an attribute, I'd
> like to use the same (or something very close to the) function
> the server is likely to use to check the syntax of my data.

> One thing we could do is have functions that deal with
> validation/prettying/normalization into the client library,
> using a schema handler if available or failing if no schema
> knowledge is present.  Then we need an API function that gathers
> (partial) schema information from a target server (or from each
> entry's subschema, or from any standard source, even, say, by
> directly parsing the schema files or so).
>
> I understand there's still the need of some wit from the user
> to collect the appropriate schema info for the purpose.

This sounds pretty interesting, but somewhat limited. Really, the way to insure
that you perform checks using the same code the server uses is to *use the
server's code*. If you want to do this without sending requests to the server,
it seems like you need to store object code in the DIT that clients can
retrieve and execute. This is the sort of flexibility that Java promises (but I
reserve judgement on whether it actually delivers or not). Of course, our
server doesn't execute Java, so that point is moot.

I've always considered this to be a weak point of the extensibility of the
X.500 model; sure you can define new syntaxes as you need them, but no one else
in the world has any idea what they mean, and no way to interpret them, without
a universal execution language. Perhaps that's overstating the problem; I guess
if you stored the ABNF of your syntaxes in the DIT, (a universal
*specification* langauge) you could then make a pretty good stab at distributed
evaluation/validation. Then all you need to do is insure that the client and
server run compatible spec parsing engines.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support