Mailing-List: contact api-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: api@directory.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Date: Fri, 27 Nov 2009 11:10:07 +0100
From: Matthew Swift <Matthew.Swift@Sun.COM>
Subject: Re: Let's start for real ?
In-reply-to: <4B0F9ABB.8050900@gmail.com>
Sender: Matthew.Swift@Sun.COM
To: api@directory.apache.org
Message-id: <4B0FA57F.7000305@sun.com>
References: <4B0C0163.9040607@nextury.com>
 <6D888D9C-17B1-40F2-B642-C5621256FF46@sun.com>
 <d45b08f00911270105v320d282dt7c62ae3cd7a4d5ff@mail.gmail.com>
 <4B0F9ABB.8050900@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre)
 Gecko/20091126 Shredder/3.0.1pre

> On 27/11/2009 10:05, Emmanuel Lecharny wrote:
>> Sure, as much as possible. This is why we picked LdapDn instead of DN,
>> and such names. I just have an issue with Attribute, because if we
>> want to write a wrapper around JNDI, it will end with ugly package
>> bnames to be added in the code to avoid confusion between Attribute
>> (jndi) and Attribute (API)...
>
> I don't think we should sacrifice the general public API 
> cleanness/homogeneity for the specific JNDI wrapper case.
>

100% agree.

> What we should be looking for is to have the best, cleanest LDAP API - 
> in the long term, it is the only one that matters.
>
> And for the confusion, well I don't think 
> javax.naming.directory.Attribute brings much of it :)
>

A couple of other points regarding JNDI interop:

    * A conversion layer may have to deal with ugly name clashes, but
      this will not usually result in application code having to deal
      with those clashes by using package names everywhere. E.g.

      // SDK Entry
      Entry e = ...;

      // JNDI Attribute
      Attribute a = ....;

      // No name pollution required here:
      e.addAttribute(JNDIAdapter.newSDKAttribute(a));

    * Personally, I'm not 100% convinced of the advantages of such a
      conversion layer since it implies that an application will contain
      a mixture of legacy API (e.g. JNDI) code and new SDK code. Another
      option is to provide a JNDI LdapContext implementation which uses
      the new SDK. Then there's no need to change any legacy code - just
      use the new LdapContext.

Anyway, we can cross this bridge when we come to it. I don't think that 
it's a priority now.

Matt