Menu
▾
▴
python-ldap-dev
|
From: <mi...@st...> - 2002-08-12 20:42:56
|
HI! Please take note of the following check-ins related to LDAPv3 schema support (see below). Tested on various servers: OpenLDAP 2.0/2.1 IBM SecureWay Lotus Domino/LDAP R5(?) Novell eDirectory 8.6.1/8.7 Novell Directory Server 4.16SP1, 5.0 Siemens Dir/X (various unknown versions) Innosoft's IDDS 4.5.1 There still might be some detailed issues. Reviews, profiling performance hot spots, testing, etc. is appreciated. If that code works reliably I will cvs remove schema support based on OpenLDAP's schema parser from C _ldap. Ciao, Michael. -------- Original Message -------- Subject: CVS: python-ldap Date: Mon, 12 Aug 2002 13:32:29 -0700 From: Michael Str?der <str...@us...> Reply-To: pyt...@li... To: pyt...@li... CVSROOT: /cvsroot/python-ldap Module name: python-ldap Changes by: stroeder 2002/08/12 13:32:29 Modified files: Demo : schema.py schema_tree.py Lib/ldap : schema.py Log message: Abandoned use of OpenLDAP's schema parser. Implemented own parsing with ldap.schema.split_tokens() and ldap.schema.extract_tokens(). Probably bad performance and robustness => peer review needed. SubSchema.name2oid is now nested dictionary separated by schema element classes. This was needed since schema element names are reused for attribute types and object classes on e.g. Novell eDirectory. ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 -- https://lists.sourceforge.net/lists/listinfo/python-ldap-commits |
|
From: Jens V. <je...@zo...> - 2002-08-12 22:11:51
|
well, for what it's worth, the schema.py and schema_tree.py demos in the=20= Demo folder work very nicely against my test server (OpenLDAP 2.1.3). as far as performance goes, the subjective performance seems to be the=20= same as it was with the other implementation. not sure if that's any = kind=20 of useful indicator, though. i think this is great stuff. thanks michael!!! i plan on using this to=20= offer select widgets in places where i had to rely on people typing=20 objectClass names into text boxes before... jens On Monday, August 12, 2002, at 04:42 , Michael Str=F6der wrote: > HI! > > Please take note of the following check-ins related to LDAPv3 schema=20= > support (see below). > > Tested on various servers: > OpenLDAP 2.0/2.1 > IBM SecureWay > Lotus Domino/LDAP R5(?) > Novell eDirectory 8.6.1/8.7 > Novell Directory Server 4.16SP1, 5.0 > Siemens Dir/X (various unknown versions) > Innosoft's IDDS 4.5.1 > > There still might be some detailed issues. > Reviews, profiling performance hot spots, testing, etc. is = appreciated. > > If that code works reliably I will cvs remove schema support based on=20= > OpenLDAP's schema parser from C _ldap. > > Ciao, Michael. > > > -------- Original Message -------- > Subject: CVS: python-ldap > Date: Mon, 12 Aug 2002 13:32:29 -0700 > From: Michael Str?der <str...@us...> > Reply-To: pyt...@li... > To: pyt...@li... > > CVSROOT: /cvsroot/python-ldap > Module name: python-ldap > Changes by: stroeder 2002/08/12 13:32:29 > > Modified files: > Demo : schema.py schema_tree.py > Lib/ldap : schema.py > > Log message: > Abandoned use of OpenLDAP's schema parser. Implemented own parsing = with > ldap.schema.split_tokens() and ldap.schema.extract_tokens(). Probably = bad > performance and robustness =3D> peer review needed. > > SubSchema.name2oid is now nested dictionary separated by schema = element > classes. This was needed since schema element names are reused for=20 > attribute > types and object classes on e.g. Novell eDirectory. > > |
|
From: <mi...@st...> - 2002-08-14 07:32:21
|
Jens Vagelpohl wrote: > as far as performance goes, the subjective performance seems to > be the same as it was with the other implementation. not sure if > that's any kind of useful indicator, though. I hoped that someone bites the bullet and uses /usr/lib/python2.2/profile.py... ;-) Also the __init__() methods of the schema element classes need review to check whether they are consistent. > i plan on using this to > offer select widgets in places where i had to rely on people > typing objectClass names into text boxes before... This is rather simple: SubSchema.all_available(ldap.schema.ObjectClass) Be warned that the API still might be changed without prominent notification (there are some significant changes in the pipe not checked in). I developed the stuff while implementing schema support in web2ldap. Therefore it should contain almost everything needed by applications. Also be warned that there are many broken schemas out there in the wild. Test your application against other products than OpenLDAP! Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-08-14 11:52:03
|
> I hoped that someone bites the bullet and uses > /usr/lib/python2.2/profile.py... ;-) hey, i told you i don't use python2.2 yet ;) > Also the __init__() methods of the schema element classes need review to > check whether they are consistent. you mean the classes inside schema.py such os "ObjectClass", "AttributeType" etc? i am noticing that the __init__ for ObjectClass, unlike all others, does not just take the full schema_element_string, it also takes all attributes as separate keyword arguments. that seems a little redundant. all other classes only take the schema_element_string and extract the attributes from that. > Be warned that the API still might be changed without prominent > notification (there are some significant changes in the pipe not checked > in). I developed the stuff while implementing schema support in web2ldap. > Therefore it should contain almost everything needed by applications. i don't have time to implement it and throw it out right at this moment, anyway. i'm fully aware that something so "new" will change more frequently. > Also be warned that there are many broken schemas out there in the wild. > Test your application against other products than OpenLDAP! well, i would probably end up doing a widget that offers both a dropdown and a text input field, maybe depending on errors occurring during schema discovery. jens |
|
From: <mi...@st...> - 2002-08-14 19:31:34
|
Jens Vagelpohl wrote: >> I hoped that someone bites the bullet and uses >> /usr/lib/python2.2/profile.py... ;-) > > hey, i told you i don't use python2.2 yet ;) Hah, that's obviously no excuse... ;-) > i am noticing that the __init__ for ObjectClass, unlike all > others, does not just take the full schema_element_string, it > also takes all attributes as separate keyword arguments. that > seems a little redundant. Python 2.2.1 (#2, May 4 2002, 19:50:26) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ldap.schema >>> str(ldap.schema.ObjectClass(oid='1.23.456.78.0',names=['myClass','myClassAlias'],must=['myRequiredAttr1','myRequiredAttr2'],may=['myAllowed1'])) "( 1.23.456.78.0 NAME ( 'myClass' 'myClassAlias' ) STRUCTURAL MUST ( myRequiredAttr1 $ myRequiredAttr2 ) MAY myAllowed1 )" >>> Also works with Python 2.1.x! ;-) Got the message? It's meant for automated schema element creation. A schema editor comes to mind... > all other classes only take the schema_element_string and > extract the attributes from that. Yes, they are not complete yet. > well, i would probably end up doing a widget that offers both a > dropdown and a text input field, maybe depending on errors > occurring during schema discovery. Error handling is somewhat subtle. Ciao, Michael. |
Thanks for helping keep SourceForge clean.
X