FutureDirections

Notes on possible future directions

ZopeLDAP 1.0 behaves a fair amount like a ZODB storage, but inside of Zope. This means that it tries its best to be transactional, and that it tries pretty hard to abstract out any sort of LDAP Specific programming on the part of the end user by turning results into mostly-Zope-ish Entry objects.

Since LDAP is not a transactional protocol, ZopeLDAP fakes transactions by delaying actual writes to the LDAP repository until commit time. It's not a foolproof scheme, but you have some assurance that if you have an application that updates both an SQL database and an LDAP directory, your data should stay in sync even if exceptions are raised. This is a powerful feature of Zope and it's only right that ZopeLDAP tries to take advantage of it.

However, this very likely comes at a high cost because there are a lot of methods and routines on the core Connection object abstracting out this behavior. This is a good thing in my opinion for situations where you want to a decent amount of writing to the repository and integrity is a concern. But when it comes to wanting to use an LDAP Connection for read-only purposes, this is a very large weight to carry.

So a possible future direction may very well include a much lighter weight read-only LDAP Connection object. LDAP Filter Methods (which are also being rethought) would work the same with this object as they would with the current LDAP Connection object, except that the Entry objects that they returned would have no features for setting new attributes and adding subentries.

Furthermore, these objects may take advantage of the Record object which is used in ZRDB (SQL Methods). Record objects have the advantage of a small memory footprint because they do not have a python __dict__ attribute. A side benefit of this is that you cannot do any setattr type functions on these objects - something that further reinforces the read-only feature and should promote a stronger Entry object for the proposed ReadOnlyLDAPConnection.