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
