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
www.iktek.com
