From sascha at free.de Thu Mar 16 00:31:02 2000 From: sascha at free.de (Sascha Gresk) Date: Thu, 16 Mar 2000 00:31:02 +0100 Subject: Future of ldapmodule References: Message-ID: <38D01D36.38F781F4@free.de> [...] > 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. 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. [...] Sascha From sascha at free.de Thu Mar 16 01:00:08 2000 From: sascha at free.de (Sascha Gresk) Date: Thu, 16 Mar 2000 01:00:08 +0100 Subject: Future of ldapmodule References: <38CF5D36.44E9F8BA@inka.de> Message-ID: <38D02408.344FA708@free.de> > 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. > >