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 > 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, 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. 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 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. Assuming we have access to the getValue() setValue() methods of course... > --- o --- > > I'll try to make some sense out of my disorderly thoughts now. > > (1) The application coder writing the logic to use the control, may not be > the same entity writing/designing the control. The application needs a > transparent parameterized view of the binary opaque data to do anything > sensible with it. Using the data just in pass through situations may occur > but it's the exception and not the rule. Yep. > (2) Regardless of the binary value encoding (i.e. json, xml, BER), it can be > marshaled into a distinct data representation that makes sense for > application coders to use. So if a specific Control subtype in addition to > the type (OID) and criticality properties, exposed all properties needed to > act on that control's content, then these properties can be populated. This > way it's actionable data that can directly be used instead of some useless > binary payload. yep. > (3) It's up to control designers/implementers, to declare what the structure > of their control is. They do this through ASN.1 for BER encoded content for > example. For our codec they should so so by providing a POJI and simple POJO > implementation of their control extending our Control interface which only > has the properties: oid, and criticality. Yep. > (4) Expose the POJO and POJI to control users. Yet hide the details of > encoding and decoding. This really does not matter to the control user who > just wants to implement some application logic. It matters not to him if the > data is encoded as JSON, XML, or ASN.1 BER. Just just wants to make the > application logic function based on the information inside. Expose this yet > hide the implementation, (encoding) details. Yep. > (5) Make a pluggable framework which supports #4. Let the control > implementor declare (POJI/POJO), and implement (components for encoding and > decoding content) the control's codec extension. The end result to users is > the same regardless of the implementation details. Yep. > (6) API's like JNDI left the pass thru door open but did it by exposing the > implementation and potentially allowing the user to shoot themselves in the > foot. Exposing the value is what I am referring to. Really that's fine if > that's all you're going to do but decide on one path. Either expose it and > don't bother representing the opaque data as actionable transparent typed > information. Or don't expose it at all and just let application code deal > with the logical typed information. I agree. But closing this door also leads to some situation like the one I mentionned. Now, let's be clear : I don't really care, we will cover probably 99.9% of 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 ? -- Regards, Cordialement, Emmanuel Lécharny