Ian Bicking: the old part of his blog

More on APE

APE saves everything - permissions, properties, source, etc, since it is a ZODB storage layer and not some magic folder or object that reads and writes things it knows to the file system. So everything gets saved. When it serializes an object, it goes through a chain of objects that can store different pieces of it, and an event tracks what persistent attributes have been dealt with. So something with properties uses the properties serializer which writes the properties to a file (or RDBMS table, etc) in a usable format, and marks those attributes as having been dealt with. Then the next serializer might be the one responsible for storing permission settings (since those are also persistent attributes). The next might serialize the text source (Python Script, ZPT Page, etc) or binary source (file, image), etc. If after all of these serializers have been used and there are still persistent attributes remaining that haven't been stored or marked as used yet, those get written out in a pickled format. Changes made on the file system, or new files added in the file system, get picked up immediately. And because it's a ZODB storage, nothing changes in how you interact with the object in the ZMI.

My terminology and specifics about how it works may not be 100% correct, but that's my understanding of how it worked as of Ape 0.7. Since 0.7, the design has actually been simplified.

Ape 0.7 worked with Zope 2.6, and I think I still have a copy of it. Or maybe it was Ape 0.6. If you're interested, I've put those old copies online at toulouse.share.

If I recall correctly, things did get a little funny when CVS was installed (basically because all of the CVS directories and their contents show up in Zope). But it worked really really well for dumping a site to the file system, editing it on the file system, and then even copying it back into a regular FileStorage based area of the ZODB - it did it all transparently, and nothing was lost.

Comment on FileSystemView vs. LocalFS
by Jeff Shell

Comments:

Thanks -- I'm trying it out now. It seems like it creates an ini file for the properties; a boring example script called test gives me a test.py file and a .test.py.properties file that looks like:

[classification]
class_name=Products.PythonScripts.PythonScript.PythonScript

[security]
local-role role="Owner" username="ianb"

That seems pretty workable. You have to edit a configuration file to make new directories available, so it can't be done purely through the ZMI (and I suspect requires a server restart).

It looks like a pretty good basis for putting legacy ZODB code into a repository, without having to mess with the code (which would make us unwittingly turn legacy code into current code, which is what we're trying to avoid ;)

# Ian Bicking