directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [ServerEntry] API stupidity...
Date Wed, 30 Jan 2008 13:15:11 GMT
Hi guys,

as usual, I just realized under my shower that the ServerEntry API is 
somehow stupid - or overly complex -. Let me explain.

What we wanted at the beginning, was an API which can deal with the 
Server _and_ the client side. Server side API has to deal with the 
schema, thus requires that some registries element are stored withing 
the objects (A ServerEntry instance contains a reference to the global 
registries, an ServerAttribute instance contains a reference to the 
associated AttributeType). So far, so good, but the client API does not 
need it.

So we divided the API into two different classes, with one common 
interface :

ServerEntry + ServerAttribute
ClientEntry + ClientAttribute

those four guys implementing the
Entry + EntryAttribute interfaces.

If you look at those interfaces, you can read this :
public interface Entry<T extends EntryAttribute<?>> extends Cloneable, 
public interface EntryAttribute<T extends Value<?>> extends Iterable<T>,

Serializable, Cloneable

This is a real burden (more likely a PITA:), because you can't use the 
interface when you write a method which manipulate attributes or entry. 
It's so pathetic to write :

Entry<T extends EntryAttribute<?>> get( String id )

when you would have prefered to write :

Entry get( String id )

This morning, I realized that it would have been *much* better if we 
have had this scheme :

ServerEntry extends ClientEntry implements Entry

As we just have to extend the CLientEntry class, we can remove the 
generic from the Entry interface.

Regarding the EntryAttribute, we can do the very same thing. More than 
that, I don't see why the EntryAttribute interface should be generic ? 
We stores Values, whatever their type is (Binary, String or Streamed). 
If we have used this scheme :

ServerAttribute extends ClientAttribute implements EntryAttribute
ServerStringValue extends ClientStringValue extends implements Value,
ServerBinaryValue extends ClientBinaryValue extends implements Value,
ServerStreamedValue extends ClientStreamedValue extends implements Value

then it would have been much more easier.

This is something I want to dig more, but I wanted to share those ideas 
with you.

Comments ?

PS : I will continue my Attributes -> ServerEntry conversion, as if we 
rewrite the classes and interface, it will be just a matter of 
refactoring using Eclipse refactoring capabilities.

cordialement, regards,
Emmanuel L├ęcharny

View raw message