FYI will get to this and others later today. Excuse the delay. Alex
On Jan 30, 2008 8:15 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> 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, > Iterable<T> > 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 > and > 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 > www.iktek.com > directory.apache.org > > >
