Hi,
here are some preliminary thoughts about the Entry class.
The Entry class
---
It's the base data structure representing an element stored into a LDAP
server. It has a name (a DN) and some attributes.
All the existing API use the same name, Entry (or LDAPEntry), except
JNDI w
On Thu, Feb 4, 2010 at 8:38 PM, Emmanuel Lecharny wrote:
> Hi,
>
> here are some preliminary thoughts about the Entry class.
>
> The Entry class
> ---
>
> It's the base data structure representing an element stored into a LDAP
> server. It has a name (a DN) and some attributes.
>
> All
On 2/4/10 8:54 PM, Alex Karasulu wrote:
On Thu, Feb 4, 2010 at 8:38 PM, Emmanuel Lecharnywrote:
I'd be careful to remove interfaces. As an API you have to allow the
broadest range of implementation possibilities. Interfaces are good to have.
When in doubt keep the interface.
Another
> Another possibility (in conjonction with he fact that we might want to have
> schema aware entries) is to use a factory to build entries, instead of
> having a constructor.
I don't know if the factory is really required here cause what I think
of is just a *Entry*. It will be aware of schema if
On Thu, Feb 4, 2010 at 10:00 PM, Emmanuel Lécharny wrote:
> On 2/4/10 8:54 PM, Alex Karasulu wrote:
>
>> On Thu, Feb 4, 2010 at 8:38 PM, Emmanuel Lecharny> >wrote:
>> I'd be careful to remove interfaces. As an API you have to allow the
>> broadest range of implementation possibilities. Interfac
I totally agree with Alex. Entry MUST be an interface - I feel very
strongly about this :-)
In ODS we take the Collections API approach by having Entry defined as
an interface and then providing several sub-implementations based on the
storage/retrieval model the implementation provides. We on
On 2/6/10 12:34 AM, Matthew Swift wrote:
I totally agree with Alex. Entry MUST be an interface - I feel very
strongly about this :-)
this is probably why ODS and ADS Entry are both interface :)
Alex is right here : having it an interface does not obliterate the future.
In ODS we take the Coll
