Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 2049 invoked from network); 31 Jan 2011 15:02:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 31 Jan 2011 15:02:27 -0000 Received: (qmail 56548 invoked by uid 500); 31 Jan 2011 15:02:27 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 56353 invoked by uid 500); 31 Jan 2011 15:02:24 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 56346 invoked by uid 99); 31 Jan 2011 15:02:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jan 2011 15:02:23 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-ww0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jan 2011 15:02:16 +0000 Received: by wwa36 with SMTP id 36so5877724wwa.1 for ; Mon, 31 Jan 2011 07:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=N8SSe64u735SvWjSMoEj7J3Gl1pOQx7TselZUqQIBRk=; b=DKYCe4FUg2s9bOv7fQWrEuN8TxnTxELUjN03z2daK+UqEbWEOZ5He+fWdHIO9qC8Px bbLFbocWvm3Cr0RlotQtuoofZzyI+/v5TJJVT48q04jlKWMIlEY8o82WRv5G1dPeKjPf WpcAXYwoEMvH00fj+ufLXplfu8z0YH77vKT3A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=D+TllVPb+hk/X8ZbsLXon7zjVGiXh6WqmVxzdk2joVN1nMYtzctdifE2cP3gfkyXb7 GmlcfpTFteN94U1DX53O3agx/EbnPR4na/jJCsTybf1fO6/bVhxvWDVhNECDxA2m7ne4 wPoiYOe3z3ZfZTo+8MMcwqRg/WxNEGxIRQKmY= MIME-Version: 1.0 Received: by 10.216.242.136 with SMTP id i8mr6130365wer.19.1296486115293; Mon, 31 Jan 2011 07:01:55 -0800 (PST) Sender: akarasulu@gmail.com Received: by 10.216.73.78 with HTTP; Mon, 31 Jan 2011 07:01:55 -0800 (PST) In-Reply-To: <4D46C616.7000907@apache.org> References: <4D46981E.5060907@gmail.com> <4D46A767.1040805@gmail.com> <4D46C616.7000907@apache.org> Date: Mon, 31 Jan 2011 17:01:55 +0200 X-Google-Sender-Auth: gfPSnyXUvhJvIfoZcqRFN6uoMr4 Message-ID: Subject: Re: Control interface From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=e0cb4e43cbf15bbc27049b25b2dd X-Virus-Checked: Checked by ClamAV on apache.org --e0cb4e43cbf15bbc27049b25b2dd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also inline ... On Mon, Jan 31, 2011 at 4:24 PM, Emmanuel L=E9charny = wrote: > Comments inline... > > > On 1/31/11 2:59 PM, Alex Karasulu wrote: > >> (3) Regardless of what is stored in the value, no application can just u= se >> it as is without some kind of component to decode, parse, or interpret >> this >> binary data. It's useless to API users otherwise. It's opaque according = to >> LDAP, but there has to be some meaning to make use of this content, and >> that >> always requires some code to convert that binary data into usable >> information. A useful representation to an API user is a parameterized >> representation making the opaque structure transparent. >> > > I can imagine a use case where someone has 2 LDAP servers, he get some > response from server A, with a control he does not know anything about, a= nd > has to send the value stored into the control without having to decode it= , > to send it as a control in a request sent to server B. > > Ok, a bit far fetched, but this *can* be a use case. > > I absolutely agree that it is possible and we have to handle this case. Jus= t putting all the points on the table for discussion. > But let's think about the replication control now. It works in a way we g= et > a cooie from the server we are contacting, and we are supposed to send th= is > cookie back to the server. What is in the cookie is irrelevant to the > client. Only the server knows about it. If the client just have to do a > getValue() to get the cookie, and a setValue( cookie ) to store it in the > request control, then we don't need to define a specific control : using = a > basic control with the correct OID and criticality is enough. > > Doing this for this one case, now exposes all cases. Why not just have a getCookie()? And in fact, in one or more of the replication controls this i= s in fact the case. Also I'm getting a new idea. Not only simple storage properties need to be exposed on these custom control interfaces, they can expose methods that return yet another control in a chain. Here in this scenario, we're getting a cookie as the opaque value. But how is that value sent off to another server for example? Is it as the same control just passed thru, or is it packaged in another control type? Or are both cases possible? Say both cases are possible. The ? which extends Control introducing new properties, can also add new methods that return other Control objects that can then be encoded accordingly by the codec. In the simple case of just sending the control back out the door as is. The= n it's merely handed back to the codec which can see the value and encode it for you. Assuming we have access to the getValue() setValue() methods of course... > > Please don't think I am pushing on this issue. In the end whatever we chose to be pragmatic we can go with that. I'm just taking a slight devil's advocate position here to reveal all possibilities. Again I think we've codec to this getValue/setValue/hasValue way because JNDI made it the only reality. We can if we like break from it using some coding techniques. How though does this translate pragmatically? (1) The codec layer should not return non-decorator objects to user code bu= t should not reveal that it is returning a decorator, they should only extend our model Control interface. (2) Unknown to users, the value is there, it's just hidden from view. (3) Controls without a specific type hence with no factory registered with the codec, can just be seen as simple Control implementations, yet without the value exposed. Underneath the hood the codec can handle the value. I agree. But closing this door also leads to some situation like the one I > mentionned. > > Yep, our main problem, is if this value needs to be transformed into some other control, or packaged into some other control, as an opaque value, the= n we cannot really do this that easily without exposing it in the Control interface. Presume we have a control that has no factory, no subtype of the model's Control interface. So we currently default to using a simple ControlImpl implementing Control, to represent it. There's no extra interface here on Control to provide a method to ask for a transformed type or the value. We kind of had this problem with transforming to JNDI Controls, which is not the same exact problem but a little similar. So for this case we added additional methods to the codec service to transform the model Control into the JNDI Control that does expose the value. While writing this I am getting more optional ideas: (1) Create a new interface called OpaqueControl which although not a Decorator, exposes only access to a copy of the value? We can ask for this OpaqueControl from the codec service. (2) Leverage the existing methods toJndiControl on the codec service which gives us a JNDI version that has access to the value. (3) Directly ask for the encoded value for a control from the codec service interface as a general purpose facility and do away with the toJndi/fromJnd= i methods on the codec. Instead utilities can be provided to do this for us, using the getEncodedValue( Control control ) on the LdapCodecService. This way we can get the value. The only problem is having to have access to the codec to get it. > Now, let's be clear : I don't really care, we will cover probably 99.9% o= f > all our client usages by not exposing the getValue()/setValue() methods. = I'm > just saying that it may force our users to implement their own classes to > handle the controls we don't provide, unless we add them in the code base= . > > Is this what we want to do ? I agree we don't want to get stuck in this situation of having to implement all these controls. But ... (1) 99.9% of the time we don't have this need to access the value (2) whatever need we have now is due to us swimming in the old JNDI way (3) having this default mechanism (ControlImpl) should suite most of the 0.01% cases (4) the rest of the 0.01% cases that #3 does not handle we can handle by exposing the encoded value on the codec service interface with one of the options above (5) if we do get stuck, we can always add new methods to interfaces in the API at any point in time, but we can not yank them out at will without deprecating You're best suited to make the call on this matter, because you understand the codec best, and at the end of the day you're making this magic in the codec possible. I'm ready to back you on whatever choice you make. I just want to share all my thoughts with you in case they may help. Also sorry for this lengthy discussion. I wanted to be thorough. Thanks, --=20 Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu --e0cb4e43cbf15bbc27049b25b2dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also inline ...

On Mon, Jan 31, 2011 at 4= :24 PM, Emmanuel L=E9charny <elecharny@apache.org> wrote:
Comments inline...


On 1/31/11 2:59 PM, Alex Karasulu wrote:
(3) Regardless of what is stored in the value, no application can just use<= br> it as is without some kind of component to decode, parse, or interpret this=
binary data. It's useless to API users otherwise. It's opaque accor= ding to
LDAP, but there has to be some meaning to make use of this content, and tha= t
always requires some code to convert that binary data into usable
information. A useful representation to an API user is a parameterized
representation making the opaque structure transparent.

I can imagine a use case where someone has 2 LDAP servers, he get some resp= onse from server A, with a control he does not know anything about, and has= to send the value stored into the control without having to decode it, to = send it as a control in a request sent to server B.

Ok, a bit far fetched, but this *can* be a use case.


I absolutely agree that it is possible= and we have to handle this case. Just putting all the points on the table = for discussion.
=A0
But let's think about the replication control now. It works in a way we= get a cooie from the server we are contacting, and we are supposed to send= this cookie back to the server. What is in the cookie is irrelevant to the= client. Only the server =A0knows about it. If the client just have to do a= getValue() to get the cookie, and a setValue( cookie ) to store it in the = request control, then we don't need to define a specific control : usin= g a basic control with the correct OID and criticality is enough.


Doing this for this one case, now expo= ses all cases. Why not just have a getCookie()? And in fact, in one or more= of the replication controls this is in fact the case.

Also I'm getting a new idea. Not only simple storage properties ne= ed to be exposed on these custom control interfaces, they can expose method= s that return yet another control in a chain.

Here in this scenario, we're getting a cookie as the opaque value. But = how is that value sent off to another server for example? Is it as the same= control just passed thru, or is it packaged in another control type? Or ar= e both cases possible?

Say both cases are possible. The ? which extends Contro= l introducing new properties, can also add new methods that return other Co= ntrol objects that can then be encoded accordingly by the codec.

In the simple case of just sending the control back out the = door as is. Then it's merely handed back to the codec which can see the= value and encode it for you.

Assuming we have access to the getValue() setValue() methods of course...

Please don't= think I am pushing on this issue. In the end whatever we chose to be pragm= atic we can go with that. I'm just taking a slight devil's advocate= position here to reveal all possibilities.

Again I think we've codec to this getValue/setValue= /hasValue way because JNDI made it the only reality. We can if we like brea= k from it using some coding techniques. How though does this translate prag= matically?

(1) The codec layer should not return non-decorator obj= ects to user code but should not reveal that it is returning a decorator, t= hey should only extend our model Control interface.

(2) Unknown to users, the value is there, it's just hidden from vi= ew.

(3) Controls without a specific type hence wit= h no factory registered with the codec, can just be seen as simple Control = implementations, yet without the value exposed. Underneath the hood the cod= ec can handle the value.=A0


I agree. But = closing this door also leads to some situation like the one I mentionned.

Yep, our = main problem, is if this value needs to be transformed into some other cont= rol, or packaged into some other control, as an opaque value, then we canno= t really do this that easily without exposing it in the Control interface.= =A0

Presume we have a control that has no factory, no subty= pe of the model's Control interface. So we currently default to using a= simple ControlImpl implementing Control, to represent it. There's no e= xtra interface here on Control to provide a=A0method to ask for a transform= ed type or the value. We kind of had this problem with transforming to JNDI= Controls, which is not the same exact problem but a little similar. So for= this case we added additional methods to the codec service to transform th= e model Control into the JNDI Control that does expose the value.

While writing this I am getting more optional ide= as:

(1) Create a new interface called OpaqueContro= l which although not a Decorator, exposes only access to a copy of the valu= e? We can ask for this OpaqueControl from the codec service.

(2) Leverage the existing methods toJndiControl on the = codec service which gives us a JNDI version that has access to the value.

(3) Directly ask for the encoded value for a contro= l from the codec service interface as a general purpose facility and do awa= y with the toJndi/fromJndi methods on the codec. Instead utilities can be p= rovided to do this for us, using the getEncodedValue( Control control ) on = the LdapCodecService.

This way we can get the value. The only problem is havi= ng to have access to the codec to get it.
=A0
Now, let's be clear : I don't really care, we will cover probably 9= 9.9% of all our client usages by not exposing the getValue()/setValue() met= hods. I'm just saying that it may force our users to implement their ow= n classes to handle the controls we don't provide, unless we add them i= n the code base.

Is this what we want to do ?

I agree = we don't want to get stuck in this situation of having to implement all= these controls. But ...

(1) 99.9% of the time we = don't have this need to access the value

(2) whatever need we have now is due to us swimming in = the old JNDI way

(3) having this default mechanism= (ControlImpl) should suite most of the 0.01% cases

(4) the rest of the 0.01% cases that #3 does not handle we can handle = by exposing=A0the encoded value on the codec service interface with one of = the options above

(5) if we do get stuck, we can a= lways add new methods to interfaces in the API at any point in time, but we= can not yank them out at will without deprecating

You're best suited to make the call on this matter,= because you understand the codec best, and at the end of the day you'r= e making this magic in the codec possible. I'm ready to back you on wha= tever choice you make. I just want to share all my thoughts with you in cas= e they may help.

Also sorry for this lengthy discussion. I wanted to be = thorough.

Thanks,
--
Alex Karasulu
My Blog ::= http://www.jroller.com/akara= sulu/
Apache Directory Server :: http://d= irectory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
--e0cb4e43cbf15bbc27049b25b2dd--