Hi,
yesturday, I conducted a review on the existing APIs for the DN class :
- Name/LdapName (JNDI) (I will call it JNDI)
- jLdap/LdapSdk (I will call it LSD)
- ApacheDS (ADS)
- OpenDS (ODS)
- UnbounID (UID)
There are some important differences. There are two sets of API,
depending on the existen
Hi Emmanuel,
Thanks for doing this (happy new year by the way!). I've put my
responses inline...
On 12/01/10 14:29, Emmanuel Lecharny wrote:
Hi,
yesturday, I conducted a review on the existing APIs for the DN class :
- Name/LdapName (JNDI) (I will call it JNDI)
- jLdap/LdapSdk (I will call
Le 13/01/2010 12:24, Matthew Swift a écrit :
Hi Emmanuel,
I'm just giveng my point of view about the following, I don't think I
can be relevant elsewhere:
Also, I strongly believe that DNs and RDNs and AVAs should be immutable
objects (as well as any other low level API type). What do you t
On Jan 13, 2010, at 1:03 PM, Francois wrote:
> Le 13/01/2010 12:24, Matthew Swift a écrit :
>> Hi Emmanuel,
>
> I'm just giveng my point of view about the following, I don't think I can be
> relevant elsewhere:
>
>> Also, I strongly believe that DNs and RDNs and AVAs should be immutable
>> obj
Francois a écrit :
Le 13/01/2010 12:24, Matthew Swift a écrit :
Hi Emmanuel,
I'm just giveng my point of view about the following, I don't think I
can be relevant elsewhere:
Also, I strongly believe that DNs and RDNs and AVAs should be immutable
objects (as well as any other low level API
Matthew Swift wrote:
On 12/01/10 14:29, Emmanuel Lecharny wrote:
Even if you decide that caching is not required then that's no reason to
develop an API which prevents you from implementing one in future. Using
a normal constructor prevents the use of a cache (or forces you to use
the pimpl i
Matthew Swift a écrit :
Hi Emmanuel,
Hi Matthew,
comments inline
2) In Java, it's pretty natural to create objects through constructor.
This may be true for constructors which compose the constructor's
parameters (e.g. list of RDNs or RDN+DN) into a new object (DN), but
it is definitel
On 13/01/10 13:03, Francois wrote:
Le 13/01/2010 12:24, Matthew Swift a écrit :
Hi Emmanuel,
I'm just giveng my point of view about the following, I don't think I
can be relevant elsewhere:
Also, I strongly believe that DNs and RDNs and AVAs should be immutable
objects (as well as any ot
On 13/01/10 13:34, Emmanuel Lcharny wrote:
Francois a écrit :
Le 13/01/2010 12:24, Matthew Swift a écrit :
Hi Emmanuel,
I'm just giveng my point of view about the following, I don't think I
can be relevant elsewhere:
Also, I strongly believe that DNs and RDNs and AVAs should be immutab
On 13/01/10 21:55, Stefan Seelmann wrote:
Matthew Swift wrote:
On 12/01/10 14:29, Emmanuel Lecharny wrote:
Even if you decide that caching is not required then that's no reason
to develop an API which prevents you from implementing one in future.
Using a normal constructor prevents the use
On 14/01/10 00:43, Emmanuel Lcharny wrote:
[...]
Well, I don't really think that it's anything but implementation
dependent, so from the API POV, it's irrelevant. As soon as we add the
valueof() methods, those who want to add a cache can do it.
It's very relevant from an API POV. Being f
Matthew Swift a écrit :
and Entry should have at least an immutable DN (and facilities to
copy an entry with a new DN or ParentDN at factory level).
If the DN is immutable, entry's DN will be too.
I think Francois is stating that Entry should have a DN getter but no
setter. In other words th
Matthew Swift a écrit :
On 13/01/10 21:55, Stefan Seelmann wrote:
Matthew Swift wrote:
On 12/01/10 14:29, Emmanuel Lecharny wrote:
Even if you decide that caching is not required then that's no
reason to develop an API which prevents you from implementing one in
future. Using a normal cons
Le 14/01/2010 22:12, Matthew Swift a écrit :
Matthew, thanks for your answer, response inlined :
I understand very well why you think Attribute could be immutable. In
fact, I went to great lengths to convert our Attribute API in OpenDS
server so that it was immutable in order to be able to opti
Matthew Swift a écrit :
On 14/01/10 00:43, Emmanuel Lcharny wrote:
[...]
Well, I don't really think that it's anything but implementation
dependent, so from the API POV, it's irrelevant. As soon as we add
the valueof() methods, those who want to add a cache can do it.
It's very relevant
Matthew Swift a écrit :
On 13/01/10 13:03, Francois wrote:
Le 13/01/2010 12:24, Matthew Swift a écrit :
Hi Emmanuel,
I'm just giveng my point of view about the following, I don't think I
can be relevant elsewhere:
Also, I strongly believe that DNs and RDNs and AVAs should be immutable
o
On 14/01/10 23:20, Emmanuel Lcharny wrote:
[...]
But for users, DN(String) covers 99% of their usage. This is how they
created DN with JNDI, and i'm not sure they want something very
different. Now, internally, othing prevent you to write something like :
public DN(String dnStr) {
retur
Matthew Swift a écrit :
public DN(String dnStr) {
return valueOf( dnStr );
}
Nothing will prevent you from writing something like that, but the
compiler will prevent you from compiling it. Get some sleep! ;-)
Doh !!! Yeah, or maybe some stronger coffee ;)
--
Regards,
Cordialement,
Emman
18 matches
Mail list logo
