[ZODB-Dev] SecureServerStorage and SecureClientStorage

[Christian Reis]

On Sat, Oct 05, 2002 at 04:43:59AM -0400, Guido van Rossum wrote:
> > Suppose instances of class X have instances of class Y as an attribute. X 
> > creates an instance of class Z to do some work on Y. Your suggested idiom 
> > (and the one we have recently abandonned) is that X holds the concrete type 
> > of Z because X creates Z. The right answer might be as simple as choosing the 
> > concrete type in Y rather than X

Interesting that this statement doesn't contradict what Guido says; in
your case, you're just saying Y should hold the reference to X (as
opposed to having it in Z). However, we are still left with the problem
of being able to provide a custom class X for Y. :-)

> That depends on the relationship between classes X, Y and Z, of
> course.  The cases that I changed in ZEO only involve two classes (per
> case) though, and I think there it works well: class X creates a Y
> instance each time a certain event happens.  Old code:

This event being X.__init__() called in many cases, but I see in ZEO at
least StorageServerStub in ClientStorage and ZEOStorage and
ManagedServerConnection in StorageServer. Oh, some in ZEOStorage, too.

Is the following patchup done just because of the order the classes are
declared? If so, is it just to keep cvs annotate and diff nicer? :-)
    
    # Patch up class references
    StorageServer.ZEOStorageClass = ZEOStorage
    ZEOStorage.DelayedCommitStrategyClass = DelayedCommitStrategy
    ZEOStorage.ImmediateCommitStrategyClass = ImmediateCommitStrategy

One side-effect is that your idiom makes the class name lookup a bit
faster as it is done in a restricted scope (instead of searching for
ConnectionManagerClass in the global scope, f.i.)

Wow, that was fast. Thanks. Let me wake Johan up.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL