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