directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Creation of a second Subentry cache
Date Mon, 03 Jan 2011 01:27:56 GMT
On Mon, Jan 3, 2011 at 2:44 AM, Emmanuel L├ęcharny <>wrote:

> On 1/3/11 1:23 AM, Alex Karasulu wrote:
>> On Mon, Jan 3, 2011 at 2:02 AM, Emmanuel Lecharny<
>> >wrote:
>>  On 1/3/11 12:53 AM, Alex Karasulu wrote:
>>>  On Mon, Jan 3, 2011 at 1:29 AM, Emmanuel Lecharny<
>>>>> wrote:
>>>>  On 1/2/11 4:05 PM, Alex Karasulu wrote:
>>>>>  +1
>>>>>> The dn2subentry cache sounds like a valid optimization and making
it a
>>>>>> top
>>>>>> level accesible cache also sounds right.
>>>>>>  I went a step further, but I sent a mail explaining this extra step.
>>>>>  Additionally i checked out depa on DnNode and it seems out of place
>>>>>> shared. Had the thought that it might be best close to where it is
>>>>>> being
>>>>>> used.  WDYT?
>>>>>>  DnNode is not ony used for subentries, it's also used by referrals
>>>>>> and
>>>>> partitions. We could move it to core-api, but I believe it's better in
>>>>> shared, as it may be used by the client API.
>>>>>  Yes I know it's being used for referrals and partitions. Usages are
>>>> apacheds-core and in apacheds-core-api.
>>>> There are no usages in the client API.
>>>>  Not yet, but I don't want to obliterate this option.
>> Agreed there's no need to "obliterate" the option. However in terms of API
>> design and maintenance conventions we can add this at any point in time
>> without any issue whatsoever. However removing it especially after the
>> shared API goes 1.0 is going to having to involve deprecation procedures.
>> We're going to be stuck with it if we are mistaken.
>> Currently it's code smell (Fowler) wreaks of a server implementation
>> detail
>> while being exposed as part of the shared API.
> This class was created when we didn't have a core-api module. At this time,
> it was plain normal to have all the data structure in shared.
No problem luckily we now have the core-api module so no need
to pollute shared with it.

I don't feel that moving it out of shared-api now is a good idea.
We can't go on feelings here. You must provide valid supporting technical
points for your view point.

I've given you solid justifications based on standard API design and
maintenance concepts. Take a look here for Josh Bloch's advice, if you don't
want to take my word for it:

See slides 15 and 14 (bullet #2, "when in doubt leave it out, you can always
add but you can never remove").

>  The client will most certainly use this data structure when we will write
>> a
>>> GUI to manage APs.
>> If and when such a Studio GUI plugin is built we can always add the data
>> structure at any time if we still feel it is necessary. However we might
>> not
>> really want to do this since Studio now depends on ApacheDS proper so it
>> can
>> see the server API's as well. There might not be a need to inject this
>> into
>> the shared API after all.
> Nope. The Schema UI in studio does not depend on Apacheds at all, and so
> are many other plugins of the project. Thus if we need to use this generic
> class DnNode somwhere unrelated to Apacheds, it's good to have it in the
> API.
Not referring to the SchemaUI bundle. In studio we have all of ApacheDS
available in the embedded ApacheDS plugin bundle. This however is not
visible outside because it's an OSGi bundle, however there's no reason why
the DnNode class cannot be accessed in a similar fashion through the AP UI
plugin bundle by having a dependency on core-api.

Essentially studio already uses the entire server in the ApacheDS plugin.
What's the big deal in having another bundle depend on core-api for managing

Keep in mind it's a generic class, ie you can handle any kind of object
> which are stored in a DN tree, like :
> DnNode<Partition>
> DnNode<Referral>
> DnNode<Subentry[]>
> DnNode<AdministrativePoint>
> as it's currently the case. I can foresee some more usage, like the AP
> handling in Studio, and frankly, such a data structure is better handled in
> shared than in core-API, IMHO.
This is not a matter of anyone's opinion (regarding your "IMHO" remark
above). There are  strong technical points for it and it's
a reversible option if in fact we see this class to best be kept in shared.
Going the opposite direction is not so easy after a 1.0 release of shared.

Plus why waste time discussing this or making such a big deal out of it?
Refactoring by moving the class to another package/module takes less than 3
seconds in the IDE and you can even use drag and drop :).

 Also DnNode is not going to be used by non-ui applications using the LDAP
>> client API proper since these administrative actions leverage simple LDAP
>> operations.
> Not anymore. The administrative actions are too complex to be easily
> handled using normal entries, and this is why we now use this structure.
You may be misunderstanding what I wrote ...

The *SERVER* uses this DnNode data structure to manage administrative
actions. There's no debate here. And I agree that something like this is
needed because of the complexity.

However my point above is that non-ui network *CLIENTS* need not use this
data structure at all. Network clients just issue add, delete, and modify
etc operations to create, delete, and alter subentries to alter
administrative areas. They do not need this specific data structure for
administrative operations to be performed, the LDAP protocol specifically
made sure of this.

Network clients don't even need schema information to issue administrative
options why would they need this data structure?

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message