Mailing-List: contact api-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: api@directory.apache.org
Received-SPF: pass (athena.apache.org: domain of ayyagarikiran@gmail.com
 designates 209.85.220.178 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
         :content-transfer-encoding;
        b=cOa0DKUy/rk9Pdlvb/78Ww0smllGsTb24vBIQpoPsJp7HIS1xKmL1tQjI4C3QNBr/E
         i/TCjDzA44XnvhPpLJe+kMEYvb4oYG659B4Uh+wAp4YaZJiKXWwCmjFUjZoPK/DLGo7c
         ES5+QlbTwo+UZ5P5ZI10DwgEFVY+SUrrSJryQ=
MIME-Version: 1.0
Sender: ayyagarikiran@gmail.com
In-Reply-To: <E7D43D38-FAC9-4FB8-8206-23D58010BBE1@marcelot.net>
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>
	<E7D43D38-FAC9-4FB8-8206-23D58010BBE1@marcelot.net>
Date: Thu, 5 May 2011 16:51:58 +0530
Message-ID: <BANLkTimESFi+petJ9c22wzW2Ms=DUOUkxQ@mail.gmail.com>
Subject: Re: Reading Binary Attributes
From: Kiran Ayyagari <kayyagari@apache.org>
To: api@directory.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, May 5, 2011 at 4:05 PM, Pierre-Arnaud Marcelot <pa@marcelot.net> wr=
ote:
>
> On 5 mai 2011, at 11:40, Kiran Ayyagari wrote:
>
>> On Thu, May 5, 2011 at 1:16 PM, Pierre-Arnaud Marcelot <pa@marcelot.net>=
 wrote:
>>> Hi Kiran,
>>>
>>> On 4 mai 2011, at 17:13, Kiran Ayyagari wrote:
>>>
>>>> On Wed, May 4, 2011 at 8:24 PM, Daniel Fisher <dfisher@vt.edu> wrote:
>>>>> On Tue, May 3, 2011 at 4:07 PM, Kiran Ayyagari <kayyagari@apache.org>=
 wrote:
>>>>>> Hi Daniel,
>>>>>>
>>>>>> On Wed, May 4, 2011 at 12:33 AM, Daniel Fisher <dfisher@vt.edu> wrot=
e:
>>>>>>> Hello,
>>>>>>> I'm doing some testing with 1.0.0-M3 and I'm having trouble reading
>>>>>>> binary attributes.
>>>>>>> Specifically for jpegPhoto in OpenLDAP 2.4.23:
>>>>>>>
>>>>>>> # jpegPhoto
>>>>>>> # Used to store one or more images of a person using the JPEG File
>>>>>>> # Interchange Format [JFIF].
>>>>>>> attributetype ( 0.9.2342.19200300.100.1.60
>>>>>>> =A0 =A0NAME 'jpegPhoto'
>>>>>>> =A0 =A0DESC 'RFC2798: a JPEG image'
>>>>>>> =A0 =A0SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
>>>>>>>
>>>>>>> the byte[] I get from Attribute#get()#getBytes() is about twice as =
big
>>>>>>> as I expect. Attribute#isHumanReadable() also returns true. Which
>>>>>>> makes me think the value has been encoded.
>>>>>>> Code snippet of what I'm doing:
>>>>>>> =A0 =A0 =A0 =A0while (cursor.next()) {
>>>>>>> =A0 =A0 =A0 =A0 =A0SearchResultEntry result =3D (SearchResultEntry)=
 cursor.get();
>>>>>>> =A0 =A0 =A0 =A0 =A0Entry e =3D result.getEntry();
>>>>>>> =A0 =A0 =A0 =A0 =A0Attribute photo =3D e.get("jpegPhoto");
>>>>>>> =A0 =A0 =A0 =A0 =A0if (photo !=3D null) {
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0byte[] bytes =3D photo.get().getBytes();
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0FileOutputStream fos =3D new FileOutputStrea=
m("photo.jpg");
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0fos.write(bytes);
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0fos.close();
>>>>>>> =A0 =A0 =A0 =A0 =A0}
>>>>>>> =A0 =A0 =A0 =A0}
>>>>>>>
>>>>>>> ldapsearch returns the value I expect. Is there some special syntax
>>>>>>> for binary values I'm missing? Thanks
>>>>>>>
>>>>>> this is due to the fact that by default the client connection is not
>>>>>> schema aware, to make it schema aware call loadSchema() method
>>>>>> of the connection before performing any operations.
>>>>>> Let us know if you still have any issues.
>>>>>> Thank you for testing.
>>>>>
>>>>> Thanks. After reviewing the source it appears that binary attributes
>>>>> are only supported with a schema aware connection. If you expose the
>>>>> BinaryAttributeDetector (maybe on LdapConnection) then clients could
>>>>> have some control without dealing with schemas. This would afford the
>>>>> same functionality that JNDI provides via the
>>>>> 'java.naming.ldap.attributes.binary' property. Just a thought.
>>>>>
>>>> don't know how JNDI detects the binary attributes, but in our case it =
is
>>>> done completely with the help of schema manager
>>>>> I also looked at the NetwokSchemaLoader and it uses a hard coded
>>>>> baseDn and filter. With a litte refactoring that class could also wor=
k
>>>>> against OpenLDAP, but currently it looks ApacheDS specific.
>>>>>
>>>> yes it is completely tied to the ApacheDS, the idea behind this loader=
 is to
>>>> have the same schema elements that the server currently uses instead
>>>> of loading a
>>>> set of default schemas.
>>>>
>>>> Another schema loader based on the data returned after querying
>>>> cn=3Dsubschema (this is the technique
>>>> which Apache Directory Studio uses) is ideal to make the client schema
>>>> aware while working with other servers.
>>>>
>>>> May be we can port that code from Studio to API, studio folks wdyt? :)
>>>
>>> Unfortunately Studio does not use (yet) the API on this part of the cod=
e.
>>> Although a complete Connection Wrapper as been created using the API an=
d works great, the code responsible for Schema loading in the LDAP Browser =
is still our older base source code, when the API didn't exist.
>>>
>>> We should really introduce a "generic" schema loader, based on the Netw=
orkSchemaLoader, but which first looks into the RootDSE to find the locatio=
n of the schema (the value of the 'subSchemaSubentry' attribute), and then,=
 on that DN loads all definitions of schema elements.
>>> This would allow to make the LdapConnection schema aware on servers pub=
lishing their schema that way (most of them).
>>> Definitely, a must have before releasing a final version of the API.
>>>
>>> I created a JIRA for this, DIRAPI-46:
>>> https://issues.apache.org/jira/browse/DIRAPI-46
>>>
>> great, thanks
>>> Specifying BinaryAttributeDetectors might also be interesting in the ca=
se where the server does not advertise the location of the its schema in th=
e RootDSE. But it would leave the connection being halfway schema aware, wh=
ich 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.
>
> Yeah, I agree.
> The only problem is when the connection does not expose its schema.
> I understand that some users will want to define, at least, their binary =
attributes, like Daniel.
> Not the most common use-case but something we really something we need to=
 consider...
>
>> 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.
>
> Hum... That's a good question.
> It raises other questions like:
> - When do we trigger the load of the schema? On first bind?
yes, after first bind, but this is only in the case if user wants to
load the schema from server
If a user prefers the default bundled schema to be loaded then we can
do so even before doing a bind.
> - Loading the schema will generate extra search requests (at least two), =
is that an issue?
>
shouldn't be an issue as this is just simple search
> Regards,
> Pierre-Arnaud


--=20
Kiran Ayyagari