FYI will get to this and others later today.  Excuse the delay.


On Jan 30, 2008 8:15 AM, Emmanuel Lecharny <> wrote:
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