Future of ldapmodule

[Sascha Gresk]

> 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 ldap at umich.edu 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.
> 
>