directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: LDAP Controls
Date Tue, 01 Mar 2005 23:43:08 GMT
David Boreham wrote:

>>> 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).
>> I was wondering that myself.  After looking at the javadocs I think 
>> its actually only capable of handling arbitrary controls.  Here's why 
>> ...
> Hmm...I was looking at:
>> First because it's an interface so it must be implemented.   It only 
>> contains the 3 general property accessor methods that apply to all 
>> controls:
>> String getID() ==> gets the control's OID
>> boolean isCritical() ==> the criticality
>> byte[] getEncodedValue() ==> the ASN.1 BER encoded representation of 
>> the control
> You're looking somewhere else, but where... ?
> Ah, here:
Yeah that's it.

> Ok, we may be talking at cross-purposes. What I'm saying is that
> I see generally good stuff relating to controls in the message/request
> code, e.g. here:

Yeah we have it in the POJO's.

> However, these objects do not seem to be propagated back to the 
> back-ends.
> E.g. they are lost by the time we get to here :

> This is the problem I was concerned about. I can see that a similar
> issue arose with __filter__, and it's added to the context envionment
> in SearchHandler.handle(). I'm proposing (for now , until a more
> elegant solution is found) to add the controls there too.
Sure we can do that.  However if they are to go into the context 
environment shouldn't we put them where they belong here in the LDAP 

Here the LDAP specific context can carry the session, request, and 
response controls.  One can also set the response controls: there is a 
setter unlike for the other controls.  This is definately a good hook.

> I agree that the fact that the controls are not parsed nor sent is
> also a problem ;) However, that's just a bit of BER, no problem really.

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.

>> So this covers the full gambit of controls.  We just need to 
>> implement them and perhaps give implementations nice decoded 
>> accessors.  Let the control know how to (decode) handle access to its 
>> elements.  This may not be that easy to do.  I think our approach in 
>> the line protocol side that handles the decoding can help out.  We 
>> know that controls must be registered and cannot be adhoc: supported 
>> controls must be present within the RootDSE.
> Yes, encoding and decoding controls is not a big problem.
>> We can easiler decode and populate registered controls that still 
>> implement this JNDI Control interface.  They simply have control
> Yes, yes, absolutely.
>> I think we can do that with the context through additions to the 
>> environment and properties.
> Ok, that's the current approach we're taking (to get
> something that works quickly at least).

Yeah I take back my comment above after I remembered the LdapContext 
interfaces for supporting Controls.  You agree?

>>> 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...
>> I know what you mean.  Perhaps we can use a ThreadLocal to hold a 
>> reference to the context associated with the operation.  What do you 
>> think?
> I think : bad idea. TLS only to be used in dire emergencies, which
> this isn't. I think better to add a session (and also operation) context
> object that is widely passed around. All servers I've ever worked on
> had this design, and I still think it's a good one.
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.

We're talking major changes to the design.  I'm fine with this though 
however I'd like to make sure we have listed all our options.

>>> 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.
>> So this is list a control for batching updates?  Is this a published 
>> control or one you devised - just curious?
> Not for batching, more for sync. It has been published
> as an RFC, but is currently defunct:
> There is at least one existing vendor imlpementation however (and soon 
> a second ;)
> Note that I would not necessarily advocate using this control
> generally, we're implementing support for it for interoperability
> reasons. Some good lightweight client sync addition to LDAP
> would be useful however. This work was being done in the
> LCUP IETF working group. This is the latest state of
> that work:
> I'm not sure if any vendor has implemented the LCUP
> protocol though.
We may need to be the first with LCUP ;) first maybe we can get 2251 
right though hehe.

>>> Another example would be indexed VLV searches, where
>>> the back-end needs access to the VLV control payload
>>> to drive its query execution engine.
>> Hmmm good point.  So let me just ask directly once again so I 
>> understand this correctly.  You're saying the Controls are not 
>> available to you because the context is not available within your 
>> backend partition?
> Yes, spot on.
Ok we must change this - let's work out exactly how we're going to do it 
in the right way.  It might take only a tiny bit longer.


View raw message