Mailing-List: contact api-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: api@directory.apache.org
Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates
 74.125.82.44 as permitted sender)
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=BUFK/irfuE1It+LQbnRA+yJwe+nfSS+tOdxwMFs0ZoepeobPugP6ldAfuWnT7JH7k5
         s1yvUaqUAt2eBocU1pcF1nLnvPWqnm+JyKITgaIaF1tqVVfYP5SLFLyY7RC0/IFDv3pm
         9DK8wl7+PixtW+hOS6sqsgqnwNHbYiKldFmAY=
MIME-Version: 1.0
Sender: akarasulu@gmail.com
In-Reply-To: <BANLkTikxspiMy5Y8ADa7DiCKggNH5Pu7HQ@mail.gmail.com>
References: <BANLkTinHeEihSqcpP92A57D7+OcN_HaNtA@mail.gmail.com>
	<BANLkTi=NoK6JPwOSvP_BgGw-QvKrC_qdkg@mail.gmail.com>
	<BANLkTimuu+d_6vwsuuRnSoFaSS=axrHcBQ@mail.gmail.com>
	<BANLkTikuctFJb2272UAAgKM_gK+cyMgLJg@mail.gmail.com>
	<E27C622D-728A-4A0E-8D80-B87AF6872667@marcelot.net>
	<BANLkTinvnX8ofozTn=X_WgA=2rXqp6n5Fw@mail.gmail.com>
	<BANLkTikWoqOtOCX4AAEwAv40S4L6Ag=v0g@mail.gmail.com>
	<BANLkTikxspiMy5Y8ADa7DiCKggNH5Pu7HQ@mail.gmail.com>
Date: Sat, 7 May 2011 00:29:26 +0300
Message-ID: <BANLkTike1u4H2cErvpmseKDdc9uMoqG+Uw@mail.gmail.com>
Subject: Re: Reading Binary Attributes
From: Alex Karasulu <akarasulu@apache.org>
To: api@directory.apache.org
Content-Type: multipart/alternative; boundary=e0cb4e43d1b92c58fd04a2a22fd0

--e0cb4e43d1b92c58fd04a2a22fd0
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 6, 2011 at 5:34 PM, Stefan Seelmann <seelmann@apache.org> wrote:

> On Fri, May 6, 2011 at 3:30 PM, Daniel Fisher <dfisher@vt.edu> wrote:
> >>> Specifying BinaryAttributeDetectors might also be interesting in the
> case where the server does not advertise the location of the its schema in
> the RootDSE. But it would leave the connection being halfway schema aware,
> which might be complicated to handle at first sight.
> >>> Something we can discuss about though.
> >>>
> >> yeah, the problem here is to link such a mechanism into the schema
> >> manager, but honestly I don't think it is a good
> >> idea to let user define some behavior to handle the attribute type
> >> apart from what is already defined in the schema through syntax.
> >>
> >> OTOH this conversation makes me think that we should also make
> >> connection schema aware by default, instead of the current choice
> >> of letting users call loadSchema() to make it schema aware.
> >
> > I think you want to support both behaviors. The vast majority of LDAP
> > clients do not need to be schema aware. They just need to read strings
> > (and sometimes bytes) from the server. Forcing a client to synchronize
> > schema updates with their server would place an undue burden on
> > application deployers that depend on LDAP.
>
> I agree with Daniel. LDAP is often used to authenticat users, so only
> a connect and bind is required. In that case loading the schema would
> be too expensive.
>

+1 Absolutely expensive!


> Another thing: the schema may be big, say up to an Megabyte. So you
> don't want to load the schema on each connect/bind. In Studio we cache
> the schema based on the createTimestamp/modifyTimestamp of the
> subschemaSubentry entry, but that's quite tricky and doesn't always
> work.
>
>
Yes a nice optimization if available.


> Loading the schema is also dependent from the access control rules.
> Some servers don't allow reading the schema for non-admin users. So in
> that case the connection can't be made schema-aware.
>
>
Yep.


> And using the built-in schema doesn't make sense at all, IMHO. If we
> don't know what the other server is it doesn't make sense to assume
> the schema would match.
>

+1


>
> > If you don't like exposing the BinaryAttributeDetector, you could
> > simply store the raw byte[] in the Attribute along with the UTF-8
> > encoded string for every attribute. If I remember correctly this is
> > what JLDAP does. Clients would then have the flexibility to use either
> > data type regardless of the schema.
>
> That's a great idea, +1
>

+1

Alex

--e0cb4e43d1b92c58fd04a2a22fd0--