python-ldap-dev — discussion among developers

Re: asynchronous search does not find referrals

[<mi...@st...>]

Michael Str=F6der wrote:
> Sometimes the solutions is too obvious. ;-)
>=20
> It definitely helps to display the search references. Add this line:
>=20
>     elif result_type =3D=3D ldap.RES_SEARCH_REFERENCE:
>         print result_data

And did I mention ldap.async? That is a convenience module exactly=20
to avoid having to deal with it yourself.

Ciao, Michael.

Re: asynchronous search does not find referrals

[<mi...@st...>]

Robert Sander wrote:
> On Fri, 9 Aug 2002 09:20:39 +0000 (UTC),
>  Michael Str=F6der <mi...@st...> wrote:
>=20
>>There was a fix related to this. You should at least use 2.0.0-pre05.
>=20
> I tried 2.0.0-pre05 with the same result:

Sometimes the solutions is too obvious. ;-)

It definitely helps to display the search references. Add this line:

     elif result_type =3D=3D ldap.RES_SEARCH_REFERENCE:
         print result_data

Also I'd like to suggest to make use of the very handy parameter=20
trace_level:

l=3Dldap.initialize('ldap://ldap.rediris.es',trace_level=3D1)

Ciao, Michael.

Re: asynchronous search does not find referrals

[<mi...@st...>]

Robert Sander wrote:
> On Fri, 9 Aug 2002 09:20:39 +0000 (UTC),
>  Michael Str=F6der <mi...@st...> wrote:
>=20
>>There was a fix related to this. You should at least use 2.0.0-pre05.
>=20
> I tried 2.0.0-pre05 with the same result:

Hmm, not sure when the fix was exactly. Can you please test also=20
the recent CVS version?

There's a temporary tar.gz of today's snapshot on

   http://web2ldap.de/download.html

Ciao, Michael.

Re: asynchronous search does not find referrals

[Robert S. <ml-...@ep...>]

On Fri, 9 Aug 2002 09:20:39 +0000 (UTC),
 Michael Ströder <mi...@st...> wrote:
> There was a fix related to this. You should at least use 2.0.0-pre05.

I tried 2.0.0-pre05 with the same result:

import ldap

print ldap.__version__

l=ldap.initialize('ldap://ldap-hm')
l.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION3)
l.set_option(ldap.OPT_REFERRALS,0)
result = l.search('o=epigenomics',ldap.SCOPE_ONELEVEL,'(objectClass=*)')
while 1:
    result_type, result_data = l.result(result, 0)
    if result_type == ldap.RES_SEARCH_ENTRY:
        print result_data
    elif result_type == ldap.RES_SEARCH_RESULT:
        print result_data
        break

print

for i in
l.search_s('o=epigenomics',ldap.SCOPE_ONELEVEL,'(objectClass=*)'):
    print i

Output:

2.0.0pre05
[('cn=admin,o=epigenomics', {'objectClass': ['person'], 'sn': ['admin'], 'cn': ['admin']})]
[('cn=updated,o=epigenomics', {'objectClass': ['person'], 'sn': ['updated'], 'cn': ['updated']})]
[('cn=readout,o=epigenomics', {'objectClass': ['person'], 'sn': ['readout'], 'cn': ['readout']})]
[('c=de,o=epigenomics', {'c': ['de'], 'objectClass': ['country']})]
[('c=us,o=epigenomics', {'c': ['us'], 'objectClass': ['country']})]
[('ou=groups,o=epigenomics', {'ou': ['groups'], 'objectClass': ['organizationalUnit']})]
[('ou=autofs,o=epigenomics', {'ou': ['autofs'], 'objectClass': ['organizationalUnit']})]
[('cn=gchange,o=epigenomics', {'objectClass': ['person'], 'sn': ['GroupChange'], 'cn': ['gchange']})]
[('ou=testtree,o=epigenomics', {'ou': ['testtree'], 'objectClass': ['organizationalUnit']})]
[]

('cn=admin,o=epigenomics', {'objectClass': ['person'], 'sn': ['admin'], 'cn': ['admin']})
('cn=updated,o=epigenomics', {'objectClass': ['person'], 'sn': ['updated'], 'cn': ['updated']})
('cn=readout,o=epigenomics', {'objectClass': ['person'], 'sn': ['readout'], 'cn': ['readout']})
('c=de,o=epigenomics', {'c': ['de'], 'objectClass': ['country']})
('c=us,o=epigenomics', {'c': ['us'], 'objectClass': ['country']})
('ou=groups,o=epigenomics', {'ou': ['groups'], 'objectClass': ['organizationalUnit']})
('ou=autofs,o=epigenomics', {'ou': ['autofs'], 'objectClass': ['organizationalUnit']})
('cn=gchange,o=epigenomics', {'objectClass': ['person'], 'sn': ['GroupChange'], 'cn': ['gchange']})
('ou=testtree,o=epigenomics', {'ou': ['testtree'], 'objectClass': ['organizationalUnit']})
(None, ['ldap://ldap-hm/ou=Inc,o=epigenomics'])

Greetings
-- 
Robert Sander
Manager
Information Systems        www.epigenomics.com        Kastanienallee 24
+493024345330                                              10435 Berlin

Re: asynchronous search does not find referrals

[<mi...@st...>]

Robert Sander wrote:
> On Fri, 9 Aug 2002 09:06:43 +0000 (UTC),
>  Michael Str=F6der <mi...@st...> wrote:
>=20
>>Uuumh, there might be some issues with search continuations. I saw=20
>>some of my async demos even lock up completely. Which version are=20
>>you using?
>=20
> It's from the Debian package version 1.9.999.pre04-1 which is
> python-ldap version 2.0.0-pre04 I think.

There was a fix related to this. You should at least use 2.0.0-pre05.

Ciao, Michael.

Re: asynchronous search does not find referrals

[Robert S. <ml-...@ep...>]

On Fri, 9 Aug 2002 09:06:43 +0000 (UTC),
 Michael Ströder <mi...@st...> wrote:
> Uuumh, there might be some issues with search continuations. I saw 
> some of my async demos even lock up completely. Which version are 
> you using?

It's from the Debian package version 1.9.999.pre04-1 which is
python-ldap version 2.0.0-pre04 I think.

Greetings
-- 
Robert Sander
Manager
Information Systems        www.epigenomics.com        Kastanienallee 24
+493024345330                                              10435 Berlin

Re: asynchronous search does not find referrals

[<mi...@st...>]

Robert Sander wrote:
> 
> I do not know if I make something wrong here, but it seems to me that
> asynchronous searching does not find referrals in the tree.

Uuumh, there might be some issues with search continuations. I saw 
some of my async demos even lock up completely. Which version are 
you using?

But it seems it works for me. web2ldap does make extensive use of 
async search when browsing (for nice handling of partial results 
and such).

Ciao, Michael.

asynchronous search does not find referrals

[Robert S. <ml-...@ep...>]

Hi!

I do not know if I make something wrong here, but it seems to me that
asynchronous searching does not find referrals in the tree. The example
code as follows:

#!/usr/bin/python

import ldap

l=ldap.initialize('ldap://ldap-hm')
l.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION3)
l.set_option(ldap.OPT_REFERRALS,0)
result = l.search('o=epigenomics',ldap.SCOPE_ONELEVEL,'(objectClass=*)')
while 1:
    result_type, result_data = l.result(result, 0)
    if result_type == ldap.RES_SEARCH_ENTRY:
        print result_data
    elif result_type == ldap.RES_SEARCH_RESULT:
        print result_data
        break

print

for i in
l.search_s('o=epigenomics',ldap.SCOPE_ONELEVEL,'(objectClass=*)'):
    print i

And the output is:

defiant gurubert 43 (/tmp): ./test.py
[('cn=admin,o=epigenomics', {'objectClass': ['person'], 'sn': ['admin'], 'cn': ['admin']})]
[('cn=updated,o=epigenomics', {'objectClass': ['person'], 'sn': ['updated'], 'cn': ['updated']})]
[('cn=readout,o=epigenomics', {'objectClass': ['person'], 'sn': ['readout'], 'cn': ['readout']})]
[('c=de,o=epigenomics', {'c': ['de'], 'objectClass': ['country']})]
[('c=us,o=epigenomics', {'c': ['us'], 'objectClass': ['country']})]
[('ou=groups,o=epigenomics', {'ou': ['groups'], 'objectClass': ['organizationalUnit']})]
[('ou=autofs,o=epigenomics', {'ou': ['autofs'], 'objectClass': ['organizationalUnit']})]
[('cn=gchange,o=epigenomics', {'objectClass': ['person'], 'sn': ['GroupChange'], 'cn': ['gchange']})]
[('ou=testtree,o=epigenomics', {'ou': ['testtree'], 'objectClass': ['organizationalUnit']})]
None

('cn=admin,o=epigenomics', {'objectClass': ['person'], 'sn': ['admin'], 'cn': ['admin']})
('cn=updated,o=epigenomics', {'objectClass': ['person'], 'sn': ['updated'], 'cn': ['updated']})
('cn=readout,o=epigenomics', {'objectClass': ['person'], 'sn': ['readout'], 'cn': ['readout']})
('c=de,o=epigenomics', {'c': ['de'], 'objectClass': ['country']})
('c=us,o=epigenomics', {'c': ['us'], 'objectClass': ['country']})
('ou=groups,o=epigenomics', {'ou': ['groups'], 'objectClass': ['organizationalUnit']})
('ou=autofs,o=epigenomics', {'ou': ['autofs'], 'objectClass': ['organizationalUnit']})
('cn=gchange,o=epigenomics', {'objectClass': ['person'], 'sn': ['GroupChange'], 'cn': ['gchange']})
(None, ['ldap://ldap-hm/ou=Inc,o=epigenomics'])
('ou=testtree,o=epigenomics', {'ou': ['testtree'], 'objectClass': ['organizationalUnit']})

This makes it impossible to use asynchronous searching on a tree with
referrals implemented.

Greetings
-- 
Robert Sander
Manager
Information Systems        www.epigenomics.com        Kastanienallee 24
+493024345330                                              10435 Berlin

Re: cidict problems

[Jens V. <je...@zo...>]

just as a FYI: we're kind of "stuck" on 2.1.3 as far as zope goes right=20=

now, so that will be the version that people run who run a recent =
version=20
of zope.

the first version of zope to "officially" support 2.2.x will be 2.7, =
which=20
is a few months away.

jens

On Thursday, August 8, 2002, at 09:42 , Michael Str=F6der wrote:

> Jens Vagelpohl wrote:
>> in your last mail you said that the UserDict.get method would turn=20
>> around and use __getitem__. this is not true, it uses "get" itself. i =
am=20
>> working on python 2.1.3, maybe this has changed in the version you =
are=20
>> using.
>
> I'm using 2.2.1.
>
>> here is the relevant code::
>>  35         def get(self, key, failobj=3DNone):
>>  36  ->         return self.data.get(key, failobj)
>
> Aaargh, that's flawed!
>
>> maybe the cidict class should override the method "get" as well?
>
> /bin/done
>
> I've also added .keys() and .items() with case-respecting handling=20
> including test cases.
>
> Everyone is encouraged to test with different Python versions (without=20=

> using option -O off course)!
>
> $ python Lib/ldap/cidict.py
>
> Ciao, Michael.
>
>

Re: cidict problems

[<mi...@st...>]

Jens Vagelpohl wrote:
> 
> in your last mail you said that the UserDict.get method would turn 
> around and use __getitem__. this is not true, it uses "get" itself. i am 
> working on python 2.1.3, maybe this has changed in the version you are 
> using.

I'm using 2.2.1.

> here is the relevant code::
> 
>  35         def get(self, key, failobj=None):
>  36  ->         return self.data.get(key, failobj)

Aaargh, that's flawed!

> maybe the cidict class should override the method "get" as well?

/bin/done

I've also added .keys() and .items() with case-respecting handling 
including test cases.

Everyone is encouraged to test with different Python versions 
(without using option -O off course)!

$ python Lib/ldap/cidict.py

Ciao, Michael.

cidict

[Jens V. <je...@zo...>]

this addition to the cidict class helps it and allows schema.py to run 
successfully:

         def get(self, name, default):
                 return UserDict.get(self, lower(name), default)


jens

Schema handling with various LDAP servers (was: fetching the structure / obejctClass defs)

[<mi...@st...>]

Hans Aschauer wrote:
> 
>>I'd like to see a base class for a LDAP syntax with a method
>>validate() which is called when setting the attribute value.
> 
> So this would mean that we change the implementation from "syntaxes are 
> instances of the syntax class" to "syntaxes are subclasses an 
> (abstract) syntax base class". Which objects would then instanciate the 
> syntax classes? Maybe some kind of attribute class instances, through 
> multiple inheritance?

This question really drives me nuts. After playing yesterday with 
kind of a hard-coded class-based syntax handling added to web2ldap 
I didn't came to a conclusion whether an attribute should simply 
be an instance of LDAPSyntax class or not. Well, think of matching 
rules. That really makes it complicated.

Frankly, I don't think it's worth the effort. I looked into sub 
schema sub entries of various public LDAP servers (Netscape 4.x, 
iPlanet 5.0, Siemens Dir/X, OpenLDAP 1.x/2.x, Innosoft, etc.) and 
the declaration of syntaxes is so different that it really does 
not make much sense to read and use the syntax and attribute type 
declarations from most of the LDAP servers.

It's a whole mess out there in the real world!

> For objectClasses, inheritance seems to 
> make sense, since they inherit from each other, and I think it would be 
> possible (in python), to build a class hirachy from server information 
> "on the fly".

There's not much you have to do with object classes.

 From my tests I noticed that e.g. declaration of inetOrgPerson 
differs on servers by various vendors (e.g. Dir/X declares 
inetOrgPerson as AUXILIARY class derived from top which violates 
RFC2798).

SubSchema.all_attrs() solves all these issues by resolving all MAY 
and MUST classes for a given list of object classes. Note that you 
can limit retrieval of sub schema sub entry to object classes by 
parameter attrs which usually saves a lot of band-width.

Ciao, Michael.

Re: Schema-API

[<mi...@st...>]

Jens Vagelpohl wrote:
 >
 > [dhcp182:src/python-ldap-HEAD/Demo] jens% python2.1 schema.py
 > ldap://waldorf.zope.com/dc=vts,dc=zope,dc=com

Does the entry dc=vts,dc=zope,dc=com exist?
What LDAP server is running on waldorf.zope.com:389?
Any niftly access control in place?

Not sure how to handle ldap.NO_SUCH_OBJECT during first search in
search_subschemasubentry_s(). I've checked in a version yesterday
2002/08/07 20:25:26 which handles that (and some weird servers
returning ldap.UNDEFINED_TYPE) slightly different.

 > [dhcp182:src/python-ldap-HEAD/Demo] jens% python2.1 schema.py
 > ldap://waldorf.zope.com/dc=vts,dc=zope,dc=com
 > Time elapsed search sub schema sub entry: 0.018
 > Traceback (most recent call last):
 >   File "schema.py", line 29, in ?
 >     subschemasubentry_entry = l.read_subschemasubentry_s(
 > [..]
 > TypeError: argument 1 must be string, not None

Well, off course here the Demo script is flawed... ;-)
l.read_subschemasubentry_s() should not be called if the result 
was None (=> sync CVS).

Ciao, Michael.

Re: Schema-API

[<mi...@st...>]

Jens Vagelpohl wrote:
> the problem is in the cidict class. when you call "get" then the method 
> "get" on UserDict gets called - which has no lowercasing of the name you 
> ask for.

Nothing wrong with that.

See UserDict.py:

     def get(self, key, failobj=None):
         if not self.has_key(key):
             return failobj
         return self[key]

Method UserDict.get() calls self.__getitem__(). I've added two 
test cases to ldap.cidict as proof that this works correctly.

Ciao, Michael.

Re: Schema-API

[Jens V. <je...@zo...>]

the problem is in the cidict class. when you call "get" then the method=20=

"get" on UserDict gets called - which has no lowercasing of the name you=20=

ask for.

jens


On Wednesday, August 7, 2002, at 04:03 , Michael Str=F6der wrote:

> Jens Vagelpohl wrote:
>> i'm trying to run the Demo/schema.py script and steppping through it=20=

>> with pdb there's an oddity i see, which prevents the script from =
running=20
>> successfully:
>> - ldapobject.py line 548 (in method search_subschemasubentry) a =
search=20
>> is done on the passed-in DN to retrieve the value for the attribute=20=

>> "subschemaSubentry". the search is successful and returns...
>> [('dc=3Dvts,dc=3Dzope,dc=3Dcom', {'subschemaSubentry': =
['cn=3DSubschema']})]
>> - in line 555 there is the following call:
>> e =3D ldap.cidict.cidict(r[0][1])  (r is the result shown above)
>> - at this point "e" has the following value:
>> {'subschemasubentry': ['cn=3DSubschema']}  (notice: =
"subschemasubentry" is=20
>> all lowercase now)
>> - now the problem is in line 556 in the call...
>> search_subschemasubentry_dn =3D e.get('subschemaSubentry', [None])[]
>
> Yes, no problem since ldap.cidict.cidict is used. I wouldn't claim =
that=20
> there is no bug. But I can't see a problem.
>
>> ... at this point the result is None and the script dies a little =
later.
>
> "Dies a little later" is a little bit unspecific. Can you please =
provide=20
> the traceback and mention which LDAP server you're using for testing?
>
> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: Schema-API

[Jens V. <je...@zo...>]

here's the traceback::

[dhcp182:src/python-ldap-HEAD/Demo] jens% python2.1 schema.py=20
ldap://waldorf.zope.com/dc=3Dvts,dc=3Dzope,dc=3Dcom
Time elapsed search sub schema sub entry: 0.018
Traceback (most recent call last):
   File "schema.py", line 29, in ?
     subschemasubentry_entry =3D l.read_subschemasubentry_s(
   File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", =
line=20
584, in read_subschemasubentry_s
     attrs
   File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", =
line=20
422, in search_s
     return =
self.search_st(base,scope,filterstr,attrlist,attrsonly,timeout=3D
-1)
   File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", =
line=20
425, in search_st
     msgid =3D self.search(base,scope,filterstr,attrlist,attrsonly)
   File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", =
line=20
419, in search
     return=20
self._ldap_call(self._l.search,base,scope,filterstr,attrlist,attrsonly)
   File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", =
line=20
95, in _ldap_call
     result =3D apply(func,args,kwargs)
TypeError: argument 1 must be string, not None
[dhcp182:src/python-ldap-HEAD/Demo] jens%

the "error" is that this call on ldapobject.py line 557 "e =3D=20
ldap.cidict.cidict(r[0][1])" all of a sudden lowercases the key=20
"subschemaSubentry" from the original search result. so when the code=20
tries to determine the value of that key, and asks for the *camelcased*=20=

version, it will get None back: "e.get('subschemaSubentry',[None])[0]"=20=

because "e" only has a key "subschemasubentry". if "e" contains the=20
original camelcased key then the script continues successfully.

jens




On Wednesday, August 7, 2002, at 04:03 , Michael Str=F6der wrote:

> Jens Vagelpohl wrote:
>> i'm trying to run the Demo/schema.py script and steppping through it=20=

>> with pdb there's an oddity i see, which prevents the script from =
running=20
>> successfully:
>> - ldapobject.py line 548 (in method search_subschemasubentry) a =
search=20
>> is done on the passed-in DN to retrieve the value for the attribute=20=

>> "subschemaSubentry". the search is successful and returns...
>> [('dc=3Dvts,dc=3Dzope,dc=3Dcom', {'subschemaSubentry': =
['cn=3DSubschema']})]
>> - in line 555 there is the following call:
>> e =3D ldap.cidict.cidict(r[0][1])  (r is the result shown above)
>> - at this point "e" has the following value:
>> {'subschemasubentry': ['cn=3DSubschema']}  (notice: =
"subschemasubentry" is=20
>> all lowercase now)
>> - now the problem is in line 556 in the call...
>> search_subschemasubentry_dn =3D e.get('subschemaSubentry', [None])[]
>
> Yes, no problem since ldap.cidict.cidict is used. I wouldn't claim =
that=20
> there is no bug. But I can't see a problem.
>
>> ... at this point the result is None and the script dies a little =
later.
>
> "Dies a little later" is a little bit unspecific. Can you please =
provide=20
> the traceback and mention which LDAP server you're using for testing?
>
> Ciao, Michael.
>

Re: Added class ldap.ldapobject.ReconnectLDAPObject

[Jens V. <je...@zo...>]

ldapurl.py has an error: in the applyDefaults method you put "for k in=20=

defaults". you meant "for k in default.keys()", correct?

jens


On Wednesday, August 7, 2002, at 03:40 , Michael Str=F6der wrote:

> Jens Vagelpohl wrote:
>> i just tried running the Demo/reconnect script and it errs out =
because=20
>> in line 7 it tries to call a method named "applyDefaults" on the=20
>> ldap_url object, which does not have such a method...
>
> Sorry, forgot to check in ldapurl.py...
>
> /bin/done
>
> Please try again.
>
> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: Schema-API

[<mi...@st...>]

Jens Vagelpohl wrote:
> i'm trying to run the Demo/schema.py script and steppping through it 
> with pdb there's an oddity i see, which prevents the script from running 
> successfully:
> 
> - ldapobject.py line 548 (in method search_subschemasubentry) a search 
> is done on the passed-in DN to retrieve the value for the attribute 
> "subschemaSubentry". the search is successful and returns...
> 
> [('dc=vts,dc=zope,dc=com', {'subschemaSubentry': ['cn=Subschema']})]
> 
> - in line 555 there is the following call:
> 
> e = ldap.cidict.cidict(r[0][1])  (r is the result shown above)
> 
> - at this point "e" has the following value:
> 
> {'subschemasubentry': ['cn=Subschema']}  (notice: "subschemasubentry" is 
> all lowercase now)
> 
> - now the problem is in line 556 in the call...
> 
> search_subschemasubentry_dn = e.get('subschemaSubentry', [None])[]  

Yes, no problem since ldap.cidict.cidict is used. I wouldn't claim 
that there is no bug. But I can't see a problem.

> ... at this point the result is None and the script dies a little later.

"Dies a little later" is a little bit unspecific. Can you please 
provide the traceback and mention which LDAP server you're using 
for testing?

Ciao, Michael.

Re: Schema-API

[Jens V. <je...@zo...>]

i'm trying to run the Demo/schema.py script and steppping through it =
with=20
pdb there's an oddity i see, which prevents the script from running=20
successfully:

- ldapobject.py line 548 (in method search_subschemasubentry) a search =
is=20
done on the passed-in DN to retrieve the value for the attribute=20
"subschemaSubentry". the search is successful and returns...

[('dc=3Dvts,dc=3Dzope,dc=3Dcom', {'subschemaSubentry': =
['cn=3DSubschema']})]

- in line 555 there is the following call:

e =3D ldap.cidict.cidict(r[0][1])  (r is the result shown above)

- at this point "e" has the following value:

{'subschemasubentry': ['cn=3DSubschema']}  (notice: "subschemasubentry" =
is=20
all lowercase now)

- now the problem is in line 556 in the call...

search_subschemasubentry_dn =3D e.get('subschemaSubentry', [None])[] =20
(notice: it expects camelcase again...)

... at this point the result is None and the script dies a little later.

jens


On Friday, August 2, 2002, at 10:23 , Michael Str=F6der wrote:

> Dear list members,
>
> please review the schema API in Lib/ldap/schema.py. There's also a =
demo=20
> script Demo/schema.py.
>
> I've tested it with OpenLDAP 2.0.x and 2.1.x, an Innosoft server and =
some=20
> Siemens Dir/X servers I found. It still chokes on Netscape/iPlanet/Sun=20=

> Directory Servers etc. with non-numeric "OID" but now with a nice=20
> exception.
>
> Up to now I only addressed the issues with finding the mandantory and=20=

> optional attribute types to a given list of object classes. It's still=20=

> far away from being a complete schema support.
>
> Please comment!
>
> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: Added class ldap.ldapobject.ReconnectLDAPObject

[<mi...@st...>]

Jens Vagelpohl wrote:
> i just tried running the Demo/reconnect script and it errs out because 
> in line 7 it tries to call a method named "applyDefaults" on the 
> ldap_url object, which does not have such a method...

Sorry, forgot to check in ldapurl.py...

/bin/done

Please try again.

Ciao, Michael.

Re: Added class ldap.ldapobject.ReconnectLDAPObject

[Jens V. <je...@zo...>]

i just tried running the Demo/reconnect script and it errs out because =
in=20
line 7 it tries to call a method named "applyDefaults" on the ldap_url=20=

object, which does not have such a method...

jens


On Wednesday, August 7, 2002, at 11:40 , Michael Str=F6der wrote:

> HI!
>
> I've added the class ldap.ldapobject.ReconnectLDAPObject. See the
> __doc__ string of recently checked in source:
>
> """
> In case of server failure (ldap.SERVER_DOWN) the implementations
> of all synchronous operation methods (search_s() etc.) are doing
> an automatic reconnect and rebind and will retry the very same
> operation.
>
> This is very handy for broken LDAP server implementations
> (e.g. in Lotus Domino) which drop connections very often making
> it impossible to have a long-lasting control flow in the
> application.
> """
>
> See Demo/reconnect.py how to deploy it.
>
> Please bring your CVS working tree in sync, review and test.
> Your feedback is appreciated!
>
> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Added class ldap.ldapobject.ReconnectLDAPObject

[<mi...@st...>]

HI!

I've added the class ldap.ldapobject.ReconnectLDAPObject. See the
__doc__ string of recently checked in source:

"""
In case of server failure (ldap.SERVER_DOWN) the implementations
of all synchronous operation methods (search_s() etc.) are doing
an automatic reconnect and rebind and will retry the very same
operation.

This is very handy for broken LDAP server implementations
(e.g. in Lotus Domino) which drop connections very often making
it impossible to have a long-lasting control flow in the
application.
"""

See Demo/reconnect.py how to deploy it.

Please bring your CVS working tree in sync, review and test.
Your feedback is appreciated!

Ciao, Michael.

Schema-API

[<mi...@st...>]

Dear list members,

please review the schema API in Lib/ldap/schema.py. There's also a 
demo script Demo/schema.py.

I've tested it with OpenLDAP 2.0.x and 2.1.x, an Innosoft server 
and some Siemens Dir/X servers I found. It still chokes on 
Netscape/iPlanet/Sun Directory Servers etc. with non-numeric "OID" 
but now with a nice exception.

Up to now I only addressed the issues with finding the mandantory 
and optional attribute types to a given list of object classes. 
It's still far away from being a complete schema support.

Please comment!

Ciao, Michael.

Re: ldap.schema: str2objectclass() fails

[<mi...@st...>]

Hans Aschauer wrote:
> On Mittwoch, 31. Juli 2002 16:46, Michael Str=F6der wrote:
>=20
>>Hans Aschauer wrote:
>>
>>>This a really easy approach to the problem. Should I commit that
>>>patch?
>>
>>Yes!
>=20
> Done. Including the patch for schema.py. It works for me, but, as=20
> always, please test it!

Seems to work.

The assertion

   assert res in ERRCODE2SCHERR.keys()

is not necessary since we use ERRCODE2SCHERR.get(res,SchemaError)=20
to use the base-class in case of unknown error code. I expect the=20
OpenLDAP project to add new error codes without us keeping up with=20
it. ;-)

Ciao, Michael.

Re: ldap.schema: str2objectclass() fails

[Hans A. <Han...@Ph...>]

On Mittwoch, 31. Juli 2002 16:46, Michael Ströder wrote:
> Hans Aschauer wrote:
> > This a really easy approach to the problem. Should I commit that
> > patch?
>
> Yes!

Done. Including the patch for schema.py. It works for me, but, as 
always, please test it!

Hans
-- 
Han...@Ph...