Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <49483CB7.8090602@apache.org>
Date: Wed, 17 Dec 2008 00:41:43 +0100
From: Stefan Seelmann <seelmann@apache.org>
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [Aliases] Questions ...
References: <4947CDA0.7040103@nextury.com>
In-Reply-To: <4947CDA0.7040103@nextury.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

Emmanuel Lecharny wrote:
> Hi guys,
> 
> First, we have an open issue since 1.0 version : DIRSERVER-803
> (https://issues.apache.org/jira/browse/DIRSERVER-803). This is a special
> case : we create an alias which is linked to an ancestor. Questions :
> 1) Should we allow such aliases ? Currently, it's rejected and seen as a
> loop.

Is it necessary for the standard certification? Then we need to allow it.

> 2) If we allow such aliases, how should we detect that we are not
> looping when doing a subtree search ?

We could put all DNs of traversed aliases (only aliases not normal
entries) to a Set or Map during the search.

> 3) What about cross referencing alias (ie alias A refers to alias B and
> vice versa) ?

This should be valid. I think it depends on the alias dereferncing mode
if this would cause a loop or not. So we need to check for a loop while
finding the search base and while performing the search.

> We have options, as we maintain a cache internally with all the entries
> which are not aliases ( a bit like what we do with referrals), but as we
> may have order of magnitudes more non-aliases than aliases, this sounds
> a bit weird to me. Shouldn't we create a cache of entries which are
> referrals instead of the opposite ? This is what we do for the
> referrals, and we initiate this cache when starting the server, reading
> all the entries with the referral AT.

Yes, makes totally sense.

Sorry, I'm to tired to answer more, maybe tomorrow.

Regards,
Stefan