Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 13881 invoked from network); 24 Aug 2009 09:03:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Aug 2009 09:03:42 -0000 Received: (qmail 86468 invoked by uid 500); 24 Aug 2009 09:04:00 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 86391 invoked by uid 500); 24 Aug 2009 09:04:00 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 86383 invoked by uid 99); 24 Aug 2009 09:04:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Aug 2009 09:04:00 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of pajbam@gmail.com designates 209.85.220.213 as permitted sender) Received: from [209.85.220.213] (HELO mail-fx0-f213.google.com) (209.85.220.213) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Aug 2009 09:03:51 +0000 Received: by fxm9 with SMTP id 9so1405684fxm.25 for ; Mon, 24 Aug 2009 02:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=NUCfqAV7v/YrN00v9E4R3hYJ+DWsU0HqsVlm5GP/mUI=; b=WN5dLCtNsD1q5rzDpwe617yS6RjixvgFmg2xbTy1q6OUp14ys9y0IWUZMXUlrGnnYg o6sXYC2OabW7sXSj3FTckr0BYx5S0v16hPuARYPuqCyiIJdhkrXXBi8EeiRxQOTCtdcA CBgDzowMwfsG067xE1AjZKYx+I9ITsD2ErsCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=SMbXOHkhLoKSkVdhoYEdHcwgGDEjIEMvFSKixSGTrUmAQipj2sDJXlpYHO5bo4tt8t JSBMv/+2kaFzR1soq0RMXadk0YIcY9avoPzATVFt1pBrwu9q/CFTQA9h5tUeTgqFSBHo eOz3g5y7vaU99Qg8u4JH1e7gaFvu8RFhhBF8U= MIME-Version: 1.0 Sender: pajbam@gmail.com Received: by 10.102.254.38 with SMTP id b38mr1091542mui.58.1251104610098; Mon, 24 Aug 2009 02:03:30 -0700 (PDT) In-Reply-To: <4A914382.4000309@nextury.com> References: <4A914382.4000309@nextury.com> Date: Mon, 24 Aug 2009 11:03:30 +0200 X-Google-Sender-Auth: 04cf6579623b256a Message-ID: <98d8c0860908240203o132da0f9m31473497c430bb8a@mail.gmail.com> Subject: Re: [Schema refactoring] OidRegistry, 2 From: Pierre-Arnaud Marcelot To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=0016364265eddc9ed00471df7d4a X-Virus-Checked: Checked by ClamAV on apache.org --0016364265eddc9ed00471df7d4a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Does this mean that a single SchemaObjectRegistry will allow the lookup of objects by name AND oid ? If yes, we would make a great use of that in Studio. Regards, P-A On Sun, Aug 23, 2009 at 3:26 PM, Emmanuel Lecharny wr= ote: > Well, after a second thought, the OidRegistry is useless. We can use the = SO > registries instead of the unique OidRegistry, as we laready have a way to > find a SO from its OID using this data structure. We just have to extend = it > by adding a name->SO to be able to cover the same functionalities offered= by > the current OidRegistry. > > -- > -- > cordialement, regards, > Emmanuel L=E9charny > www.iktek.com > directory.apache.org > > > > --0016364265eddc9ed00471df7d4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Does this mean that a single SchemaObjectRegistry will allow the lookup of = objects by name AND oid ?

If yes, we would make a great = use of that in Studio.

Regards,
P-A

On Sun, Aug 23, 2009 at 3:26 PM, Emmanuel Le= charny <elecha= rny@apache.org> wrote:
Well, after a second thought, the OidRegistry is useless. We can use the SO= registries instead of the unique OidRegistry, as we laready have a way to = find a SO from its OID using this data structure. We just have to extend it= by adding a name->SO to be able to cover the same functionalities offer= ed by the current OidRegistry.

--
--
cordialement, regards,
Emmanuel L=E9charny
www.iktek.com
directory.apache.= org




--0016364265eddc9ed00471df7d4a--