Re: Syntax functions in client library?

[Pierangelo Masarati <masarati@aero.polimi.it>]

> 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, 

your clear sight of the implications of the problem is amazing, 
I didn't see it to this depth, really.  However, I'm trying to 
solve a practical problem: assuming I use OpenLDAP both on server
and client library side (and provided I deal with standard syntaxes
and OpenLDAP correctly implements the syntax checks), can I minimize 
the number of syntax-related update failures?  I think that moving 
a few functions to the client library side (with the necessary 
reworking, of course) could add generality at nearly zero cost.  

I would leave the parsing engines spec and ABNF storing in the 
server to a working group, which is possibly the only place that 
could come out with a truly standard and acceptable solution; of
course OpenLDAP could be that group :)

Pierangelo.