directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ServerEntry] API stupidity...
Date Wed, 30 Jan 2008 17:24:00 GMT
FYI will get to this and others later today.  Excuse the delay.

Alex

On Jan 30, 2008 8:15 AM, Emmanuel Lecharny <elecharny@gmail.com> 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
>
>
>

Mime
View raw message