directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Boreham" <da...@bozemanpass.com>
Subject Re: LDAP Controls
Date Wed, 02 Mar 2005 14:19:24 GMT
> More so than this being a  BER issue was the fact that the control can 
> have any structure.  We had no clue what would be a registered control so 
> what could we do?  I guess with the present decoder which will be ousted 
> you could add rules for processing a specific control pretty easily. 
> There's a rule based digester approach.  Extensibility of the digester is 
> high but its a tough thing to maintain, hence the desire to rewrite it.  I 
> hope we keep our focus and make sure for the sake of easily adding 
> controls we make the decoder encoder pair extensible for the variable 
> payloads of Controls.

I think you're imagining this to be more than it needs to be.
Instead just punt the encoding/decoding
of controls to the code that uses them. If I add a whizbang-special control
that is used in my whizbang-special custom back-end, then I need to write
code to encode and decode that control. Just make the raw BER control
payload available to my code and I'm happy. So in the request message
parser, when you see controls, only parse them down to a collection of
OIDs and payload BER. Similarly when encoding a response message,
take a collection of OIDs and payload BER that may have already been
placed in the controls collection during operation processing.
Of course encoder/decoders
for common controls can be supplied in canned form, that's fine too.
I think where you're headed is a science project : much easier to just
say that if you use a control, then you have responsibility for its encoding
and leave it at that.

> Hmmmm I don't like the passing around idea which changes interfaces and 
> signatures (API/SPIs).  The operation information can be stuffed into the 
> JNDI Context as we spoke about within the Env or even within the 
> LdapServerContext which implements LdapContext in the server side JNDI 
> provider.  Perhaps we even allow access to the session this way.  I don't 
> like the env sometime because I think these objects can be removed from 
> it.  Access via type safe methods might be better.

I think we're saying the same thing here. Perhaps an example will help:
Currently we have methods on the partition classes something like this:
delete (delete_this_dn)
If, inside the implementation of the delete operation, it turns out
that we need access to more information than the identity of the
entry to delete, we're out of luck.
I'm saying that we need interfaces like this:
delete (delete_this_dn, some_context_object)
So, when we need access to more information about the
session or the operation, we can get it
(directly or indirectly) from that context object.

I don't much care what type the context object has:
the JNDI context is fine, the LdapContext is fine.
All I care about is that it exists ;)



Mime
View raw message