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