Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of david@bozemanpass.com
 designates 69.145.82.195 as permitted sender)
Message-ID: <38e101c51eac$9afb0f00$da529145@mtbrook.bozemanpass.com>
From: "David Boreham" <david@bozemanpass.com>
To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>
References: <4224AAB2.9040700@bellsouth.net>
 <0c2101c51e88$2fed6600$fb529145@mtbrook.bozemanpass.com>
 <4224D08C.9000901@bellsouth.net>
 <389601c51e9f$41e44740$da529145@mtbrook.bozemanpass.com>
 <4224E0F5.9090901@bellsouth.net>
Subject: Re: LDAP Controls
Date: Tue, 1 Mar 2005 14:18:33 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit

>> 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:
http://java.sun.com/j2se/1.4.2/docs/api/javax/naming/directory/SearchControls.html

> 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:
http://java.sun.com/j2se/1.3/docs/api/javax/naming/ldap/Control.html

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:
http://svn.apache.org/viewcvs.cgi/incubator/directory/ldap/tags/internal-release-0.8/common/src/java/org/apache/ldap/common/message/Message.java?rev=125226&view=markup

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 :
http://svn.apache.org/viewcvs.cgi/incubator/directory/apacheds/trunk/protocol/src/main/java/org/apache/ldap/server/protocol/SearchHandler.java?rev=151811&view=markup
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.

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.

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

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

>> 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:
http://quimby.gnus.org/internet-drafts/draft-armijo-ldap-dirsync-00.txt
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: http://www.ietf.org/rfc/rfc3928.txt
I'm not sure if any vendor has implemented the LCUP
protocol though.

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