Re: unicode value

[Alain S. <asp...@gm...>]

On 5/24/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> > On 5/23/07, Michael Str=F6der <mi...@st...> wrote:
> >>
> >>
https://sourceforge.net/tracker/?func=3Ddetail&atid=3D352072&aid=3D616567&g=
roup_id=3D2072
> >
> > - First, encode data when sending request to ldap server.
> > Do you know an drawback to encode any unicode sting into utf-8 ?
>
> Did you read my comment in the tracker item above? I repeat it here:

Yes I did !

>
> "One cannot always assume UTF-8 encoded Unicode strings in
> attribute values. Think of attributes jpegPhoto,

When writing my ldap.search() request I know jpegPhoto is raw data and not =
a
string !
This is why I will use 'jpegPhoto'  and not u'jpegPhoto' in the attribute
list.
On the other hand, I will never use a unicode string for a jpegPhoto value
in ldap.modify() or ldap.add().

> userCertificate, etc. Therefore there's no generic way to
> handle that at the API level without knowledge about the
> syntax defined in the LDAP schema.
> (Note that this has been debated to death on python-ldap-dev
> mailing list.)"
>
> > -Second, decode data coming back from the server.
> > The only function to retrieve data is search(), right ?
>
> Not necessarily. Think of LDAP extended operations, like whoami_s().
>
> > what about the use of this kind of request ?
> > ldap_con.search_s(base_dn, ldap.SCOPE_BASE, filter, ['cn', 'mail',
> > u'givenName', u'sn' ])
> >
> > that way, python-lib know that attribute givenName and sn should be
> > decoded into unicode  string.
>
> This will be cumbersome. You will have to pass these attributes into
> method result() which in general has no knowledge about a particular
> request it's receiving results for. And I'll keep it like this because I

Ops, I forgot the asynchronous side of ldap, but the msgid make the link
between both
the request and the result and a dictionary store in the ldapobject could
store the
unicode transcoding info used in the request. And then ldap.result(), could
use these
info to decode the value when user call it.

> still have the idea for implementing a connection pool with less thread
> locking. Also it's not only a question of Unicode or not.

[OFF-TOPIC] You are speaking about thread, I used asynchat for 2 different
projects.
This could be an option for python-ldap

> It's very simple to implement a small wrapper class sufficient for
> simple applications. But I'm against doing this in the general
> python-ldap API.

Yes of course a wrapper around each function to convert input and output.
Thanks for your advice.

I'start writin a wrapper for search() and modify() now.

I send you my results as soon a possible.

Best regards.

Alain

--
Alain Spineux
aspineux gmail com
May the sources be with you