python-ldap-dev

Future of ldapmodule

[David L. <dav...@cs...>]

On Tue, 14 Mar 2000, Sascha Gresk raved thusly:

> > Future of ldapmodule
> > Since I saw SWIG, I have since realised how much more simple and
> > portable I could have made this module. Most of the work is in
> > converting Python data structures into C data structures and testing
> > for errors and raising exceptions wherever possible.
> 
> This is just a beginning, but now I can start to use python and LDAP .

> LDAP
> LDAP/CVS
> LDAP/CVS/Root
> LDAP/CVS/Repository
> LDAP/CVS/Entries
> LDAP/ldapmodule.h
> LDAP/Makefile
> LDAP/lber.i
> LDAP/ldap.i
> LDAP/test.py
> LDAP/link.conf
> LDAP/link
> LDAP/VERSION
> LDAP/README.static
> LDAP/TODO
> LDAP/README

Sasha,

this looks like a great start!  much smaller and understandable. and even 
the lber interface is exposed.

but which particular LDAP library was this created against? the various ldap
header files that are around (netscape/openldap/umich) may not work with 
what you have - as not all those functions would be available everywhere
i reckon.

also, in order to retain the niceness features that the current module
has (exceptions, integrated memory management) a lot of wrapping needs to
happen. while it this is possible and probably a good design, keeping it
independent, there is still i believe some uncertainty about what the
'top level' python LDAP client API should look like.

i reckon the API should follow what CORBA are doing. Alternatively, the
python dbm module interface could be used - but X.500 DNs are just
so less compatible than most database's free-form keys... originally
I tried to base the python interface on an RFC, but it just doesn't seem
to fit very where. fo...@so... and mi...@ms... have some good
ideas in this area, but have been quiet of late.

> You are welcome to join and/or use this for extending your efforts to
> convince python to talk LDAP ...

so the .i files that you have shown me look like a nice way of getting
rid of a lot of redundant existing code, but at this first glance, i
think it needs a lot of work to get it to be more portable, and also 
our minds need to be made up on what the LDAP api should really look like..

i'd encourage you to work this into the python-ldap source tree.

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-624  Ph:+61 7 336 52447
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

les Windows est un système d'exploitation - Babelfish

Re: Future of ldapmodule

[Michael <mic...@in...>]

David Leonard wrote:
> 
> On Tue, 14 Mar 2000, Sascha Gresk raved thusly:
> 
> > This is just a beginning, but now I can start to use python and LDAP .
> > [..]
> > LDAP/lber.i
> > LDAP/ldap.i
> > [..]
> 
> Sasha,
> 
> this looks like a great start!  much smaller and understandable.
> [..]
> while it this is possible and probably a good design, keeping it
> independent, there is still i believe some uncertainty about what the
> 'top level' python LDAP client API should look like.
> [..]
> i reckon the API should follow what CORBA are doing.

I do not exactly know what Corba is doing. But I think the low-level
LDAP C module should not abstract to such a high level (like e.g.
JNDI).

> Alternatively, the
> python dbm module interface could be used

I don't think this is a good idea. If someone has the need for such
a interface he should write a wrapper class.

> fo...@so... and mi...@ms... have some good
> ideas in this area, but have been quiet of late.

I was very busy the last time...

> and also
> our minds need to be made up on what the LDAP api should really look 
> like..

I would suggest that ldapmodule stays as close to the C API as
possible with having exception for error handling just as it is
right now. Higher level abstractions (all kind of schema handling)
can be build into a separate Python class library (e.g. fog's
modules).

Note that there's a new upcoming C-API standard which will replace
RFC1823. There was a posting on ld...@um... or one of the
OpenLDAP lists about this a couple of days ago with hints how to use
autoconfigure to determine the C-API capabilities.

For me as a LDAP client programmer there are two main issues which
can only be solved within the C module:

- LDAPv3
  (I have to at least be able to tell the server that my program
  is a LDAPv3 client.)
- SSL

Both features can be achieved by sitting on top of the Netscape
library found on http://www.mozilla.org/. I think we should reach
the same level like PerlLDAP (also found on Mozilla).

Ciao, Michael.

Re: Future of ldapmodule

[Sascha G. <sa...@fr...>]

> I would suggest that ldapmodule stays as close to the C API as
> possible with having exception for error handling just as it is
> right now. Higher level abstractions (all kind of schema handling)
> can be build into a separate Python class library (e.g. fog's
> modules).
> 

Implementing ...
Now the discussion is : typemaps or classes ? 

> Note that there's a new upcoming C-API standard which will replace
> RFC1823. 

Now its on my task-list to read it !

>There was a posting on ld...@um... or one of the
> OpenLDAP lists about this a couple of days ago with hints how to use
> autoconfigure to determine the C-API capabilities.
> 

I dont really like the idea of running huge shell-skripts every time I
change
the platform, but anyway - could you be so kind to forward some of these
e-mails
so I can see how to determine the C-API capabilities ?

> For me as a LDAP client programmer there are two main issues which
> can only be solved within the C module:
> 
> - LDAPv3
>   (I have to at least be able to tell the server that my program
>   is a LDAPv3 client.)

Well SWIG can wrap this for you ...

> - SSL

Again SWIG can wrap this for you....

> 
> Both features can be achieved by sitting on top of the Netscape
> library found on http://www.mozilla.org/. 

Thanx for this pointer, I absolutly can agree SSL and LDAPv3 are 
features which should be supported.

I think we should reach
> the same level like PerlLDAP (also found on Mozilla).
> 

I'll have a look at this - bye,  Sascha


> Ciao, Michael.
> 
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/python-ldap-dev

Re: Future of ldapmodule

[<fo...@mi...>]

Scavenging the mail folder uncovered Sascha Gresk's letter:
> 
> > I would suggest that ldapmodule stays as close to the C API as
> > possible with having exception for error handling just as it is
> > right now. Higher level abstractions (all kind of schema handling)
> > can be build into a separate Python class library (e.g. fog's
> > modules).
> > 
> 
> Implementing ...
> Now the discussion is : typemaps or classes ? 

are you duplicationg my work? pls, give a look on it...

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
           Nobody will ever need more than 640k RAM! -- Bill Gates, 1981
           Windows 95 needs at least 8 MB RAM.       -- Bill Gates, 1996
           Nobody will ever need Windows 95.       -- logical conclusion

Re: Future of ldapmodule

[Sascha G. <sa...@fr...>]

Federico Di Gregorio wrote:
> 
> Scavenging the mail folder uncovered Sascha Gresk's letter:
> >
> > > I would suggest that ldapmodule stays as close to the C API as
> > > possible with having exception for error handling just as it is
> > > right now. Higher level abstractions (all kind of schema handling)
> > > can be build into a separate Python class library (e.g. fog's
> > > modules).
> > >
> >
> > Implementing ...
> > Now the discussion is : typemaps or classes ?
> 



> are you duplicationg my work? pls, give a look on it...
> 

Sounds funny - what youre doing ? - I send you the source in a separate
letter now ...


[...]

Sascha

Re: Future of ldapmodule

[<fo...@mi...>]

Scavenging the mail folder uncovered Sascha Gresk's letter:
> Federico Di Gregorio wrote:
> > are you duplicationg my work? pls, give a look on it...
> > 
> 
> Sounds funny - what youre doing ? - I send you the source in a separate
> letter now ...

uh, ok. i made (another) mistake. your code is a low-level API.
i thought you were building some high-level python classes too,
exactly what i am doing. (the swig stuff looks really nice.) 

ciao,
federico
 
-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
             Quis custodiet ipsos custodes? -- Juvenal, Satires, VI, 347

Re: Future of ldapmodule

[<fo...@mi...>]

Scavenging the mail folder uncovered Michael Ströder's letter:
> I would suggest that ldapmodule stays as close to the C API as
> possible with having exception for error handling just as it is
> right now. Higher level abstractions (all kind of schema handling)
> can be build into a separate Python class library (e.g. fog's
> modules).

i agree. michael, last time you were suggesting various changes to
my implementation, mainly to deal with schema. can you elaborate a
little bit more? i think you had better ideas then me on the argument
and i don't want to start piling up code without your 

some general questions:

has somebody tried my wrapper module or the lappo client? i didn't
received any comments on both.

any release of python-ldap at the horizon? i like much better to release
and get feedback than try do do all right from the start :)

ciao,
federico

> For me as a LDAP client programmer there are two main issues which
> can only be solved within the C module:
> 
> - LDAPv3
>   (I have to at least be able to tell the server that my program
>   is a LDAPv3 client.)
> - SSL
> 
> Both features can be achieved by sitting on top of the Netscape
> library found on http://www.mozilla.org/. I think we should reach
> the same level like PerlLDAP (also found on Mozilla).

yes, but i think the best thing is to not force a particular library
upon the user but let him choose... (autoconf/automake?)

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
              All programmers are optimists. -- Frederick P. Brooks, Jr.

Re: Future of ldapmodule

[Sascha G. <sa...@fr...>]

[...]
> Sasha,
> 
> this looks like a great start!  much smaller and understandable. and even
> the lber interface is exposed.

Dynamic loading complained about missing lber functions - so I fixed it
by supporting it ... 

> 
> but which particular LDAP library was this created against? 

Freebsd:	openldap-1.2.9 without kerberos-support (its no problem to
support kerberos)
Linux:		slapd 1.2.7-Release (Tue Nov  9 01:18:47 GMT 1999)
Solaris:        version=slapd 1.2.7-Release (Thu Jan 13 21:52:44 MET
2000)

>the various ldap
> header files that are around (netscape/openldap/umich) may not work with
> what you have - as not all those functions would be available everywhere
> i reckon.

Thats right. I'll be installing an additional (netscape/umich) -
environment on all
my three platforms - then I need to be automatically running "cvs
checkout swig-ldap; make test" 
every day on each platform to see what I have done to the sources ...

PS: Solaris 8 supports ldap as well, so again another lib and some
different header for that as well ...
    ... in a month or two I can have another sun running solaris 8

> 
> also, in order to retain the niceness features that the current module
> has (exceptions, integrated memory management) a lot of wrapping needs to
> happen.

Exceptions are really easy to implement. Memory management and
datastructures need
work. C-datatypes can be mapped to something more useful by "typemaps" -
have a look
at the brandnew site http://swig.cs.uchicago.edu/typemap/index.php3 to
get an idea -
I'll have to consult the manual to understand all this mind-transforming
stuff ...
. 

> while it this is possible and probably a good design, keeping it
> independent, there is still i believe some uncertainty about what the
> 'top level' python LDAP client API should look like.
> 

We can support several API's by providing several kind of
interface-files:

	- low-level C (just survive)
	- classic     (your module-existing programs run without modification)
	- dbm         (cool)
	- corba       (luxus)

> i reckon the API should follow what CORBA are doing. 

Can you please send me an URL or a document to help me understand how
corba supports LDAP ?

>Alternatively, the
> python dbm module interface could be used - but X.500 DNs are just
> so less compatible than most database's free-form keys... 

Okay - i'll be having a look at the dbm interface to get an opinion.

>originally
> I tried to base the python interface on an RFC, but it just doesn't seem
> to fit very where. fo...@so... and mi...@ms... have some good
> ideas in this area, but have been quiet of late.
> 
> > You are welcome to join and/or use this for extending your efforts to
> > convince python to talk LDAP ...
> 
> so the .i files that you have shown me look like a nice way of getting
> rid of a lot of redundant existing code, but at this first glance, i
> think it needs a lot of work to get it to be more portable, and also
> our minds need to be made up on what the LDAP api should really look like..
> 

Which platforms do you want to support - these platforms need the 

	"cvs checkout swig-ldap; make test" ; cvs commit test.out

so I can see if they need help ... 


> i'd encourage you to work this into the python-ldap source tree.

A first step could be implementing the classic interface.

[...]


		Sascha