directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Boreham" <da...@bozemanpass.com>
Subject LDAP Controls
Date Tue, 01 Mar 2005 20:43:00 GMT
Heads up on one thing we're working on here:

We're writing a new Backend class.
It needs to implement special behavior depending 
on the presence and value of an LDAP control
attached to the operation request PDU.

The current code doesn't seem to allow easy access
to the LDAP controls from inside a back end (the
JNDI controls class doesn't handle arbitrary
controls, I believe).

Anyway, at present we're hacking the controls
object that comes with the Request into the env Map
that's passed to the back end 's search method.
That should work for what we need to do,
but it's an evil hack.

I was wondering what the plans are for things like this?
Typically one sees a catch-all 'context' or 'session' object
that's passed in every call, that allows code anywhere to
get at things like the authId for the current operation,
things like that, with accessor methods. 
Such an object could also be used
to access controls (and also write response controls
back onto the response).

I realize this isn't great 'object design perfection',
but OTOH it's a real pain to be always finding that
there's no way to get the @*@#^ thing that you
need in your code 15 levels down the stack from
where it was last seen...

The particular example at hand is a syncronization
control that carries an update vector used in the
back-end to determine the set of entries modified
since that update vector was generated.

Another example would be indexed VLV searches, where
the back-end needs access to the VLV control payload
to drive its query execution engine.




Mime
View raw message