Future of ldapmodule
sascha at free.de
Thu Mar 16 00:31:02 CET 2000
> 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
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
>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
Exceptions are really easy to implement. Memory management and
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
> 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
- 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 ?
> 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.
> I tried to base the python interface on an RFC, but it just doesn't seem
> to fit very where. fog at sourceforge.net and michael at ms.inka.de 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.
More information about the python-ldap