At 02:46 PM 5/13/99 -0400, Chris Petrilli wrote:

Gang,

In order to get some new projects kicked off, we are going to be commissioning a ZLDAPMethods product that will provide OO access to the LDAP database world. In order to get this as "right" as possible on the first round, attached you will find, a PDF overview of the architecture (VERY early, forgive me :-) here:

http://www.zope.org/Projects/ZLDAPMethods/ZLDAPMethods.pdf

Please let me know (either directly, or via the list) of any input you might have.

It would be nice for a ZLDAPMethod to be able to override the default binding name and password, using parameters to the LDAPMethod. This would be useful for applications which must modify data in the LDAP server, but wish to use the LDAP server's security rules to determine whether the current user can perform the modification(s). It would also be useful for performing authentication when the Zope server is not allowed a login ID of its own on the LDAP server, but must use BIND operations to validate users. Granted, this is more relevant to an LDAPUserFolder type object. Another "nice to have" would be caching control, and access to the various other connection-oriented parameters which ldapmodule and most LDAP SDK's usually provide. In particular, the ability to specify when and whether LDAP aliases will be dereferenced. Some other notes, in no particular order... * It seems to me the document spends a lot of time talking about LDAP search filters, but not how to fill in parameters, which would be like ZSQL docs talking about SQL syntax, but not explaining how to put in #sqlvar tags. * LDAP is described as a connectionless protocol. It isn't. CLDAP is a variant protocol which provides only limited functionality compared to the full protocol. * I notice there is a reference to LDAP over SSL - does this mean you will be developing your own extension module for this instead of using the (OpenLDAP-based) ldapmodule? AFAIK, OpenLDAP and ldapmodule do not support SSL at the present time. * The subject of multi-valued attributes appears to have been completely overlooked, as well as delete and modify-rdn operations. I realize these may all be outside the scope of your current project, but it might be good to explicitly list what things are out-of-scope. * There are some miscellaneous DTML errors; for example: <!--#var result.c--> Should be <!--#var "result.c"--> And so on. By the way, I've been actively hacking the contributed ZLDAP product to do things like automatically re-connect the connection object upon errors, make the returned results Acquisition.Implicit so they can have methods wrapped around them, etc., and I was looking at adding some more features to do some of the above. If you guys are making a standard product for this sometime soon, I'd be happy to help with testing or even coding additional features. Let me know.