directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: About the Control interface
Date Mon, 25 Jan 2010 12:56:56 GMT
Matthew Swift a écrit :
> <snip/>
>    GenericControl(String oid) // non-critical, null value
>    GenericControl(String oid, boolean isCritical) // null value
Makes sense to add this constructor, but for Control with *no* value 
(semantically more accurate, compared to *null* value).
>    GenericControl(String oid, boolean isCritical, ByteString bytes)
byte[] fits well, I think.
> <snip/>

> The Control API must distinguish between null values (i.e. value not 
> present) and empty values (i.e. value present but zero-length).
Absolutely. I mis-judged this need, so we should add this method :

boolean hasValue();
> I don't know if it is out of scope for now, but do we want to support 
> extensibility? In particular, how can client applications implement 
> their own controls? There are two main issues here that I have 
> encountered:
>   1. Decoding of response controls: if I have a response control whose
>      type is "MyControl" do I want the LDAP SDK to automatically decode
>      it to this type? Or will the client application have to do it.
>      Here's some pseudo code to illustrate my point:
>           // Result contains a MyControl response control.
>           Result result = connection.add(entry);
>           // Option #1: Uses an internal map of Control implementation
>      classes -> OID + decoder
>           MyControl control = result.getControl(MyControl.class);
>           // Option #2: Uses an internal map of OID -> decoder
>           MyControl control = (MyControl) 
> result.getControl(MyControl.OID);
>           // Option #3: No internal map - client has to manually decode
>           Control control = result.getControl(MyControl.OID);
>           MyControl myControl = new MyControl(control);
>      I prefer the first approach for simplicity but it requires a
>      public API for registering Control implementations (as does option
>      #2) or use introspection and require that all implementations
>      provide an OID field and a constructor having a single Control
>      argument. Option #3 is quite verbose for clients IMO.
>      I think that it's safer if the request/response API decodes the
>      Control each time rather than caching the decoded control. This
>      will make it possible to support immutable request/responses.
>      If it sounds like I getting ahead here, the point of this issue is
>      that if we want to provide an simple decoding mechanism like #1
>      then we will need to have some way for the SDK to be able to
>      decode the Control. This means either having a registration
>      process, or using introspection and having a well defined
>      constructor and OID field.
>      The same problem will present itself for the following API features:
>          * decoding extended responses
>          * decoding intermediate responses
>          * decoding request controls (server-side so out of scope)
>          * decoding extended requests (server-side so out of scope)
>   2. Encoding/decoding controls: many control values are encoded using
>      ASN1. Do we want to provided ASN1 support? This will also apply
>      for new extended operations.
> I think that these questions are only applicable if we decide to 
> support extensibility.
Well, IMO, from the client side, these issues can occur only if the 
provided API does not support some of the server's Controls. In this 
case, the user will have to create his own Control, implementing the 
Control interface, and do the decoding himself. What the API will 
generate is a instance of Control where the ID, criticality and value 
are stored as opaque elements - especially for the value -. Up to the 
user to translate this instance to its own control.

I'm not sure that providing anything more complex ATM is usefull. Who 
develops Controls, anyway ?

Emmanuel Lécharny

View raw message