directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: Creation of a second Subentry cache
Date Mon, 03 Jan 2011 00:44:36 GMT
On 1/3/11 1:23 AM, Alex Karasulu wrote:
> On Mon, Jan 3, 2011 at 2:02 AM, Emmanuel Lecharny<elecharny@gmail.com>wrote:
>
>> On 1/3/11 12:53 AM, Alex Karasulu wrote:
>>
>>> On Mon, Jan 3, 2011 at 1:29 AM, Emmanuel Lecharny<elecharny@gmail.com
>>>> 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 in
>>>>> 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 in
>>> 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.

I don't feel that moving it out of shared-api now is a good idea.
> 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.

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.
> 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.


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message