You are not logged in Log in Join
You are here: Home » Members » Jeffrey P Shell » ZopeLDAP 1.1.0 » ZopeLDAPWiki » FutureDirections

Log in
Name

Password

 
 

History for FutureDirections

??changed:
-
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.