Hello, A co-worker of mine had an idea I thought was interesting and would like to investigate further. First of all, the history behind: We had requirements for: - Out of synch editing: Editing objects that are currently "published" and publishing those only once they've been workflowed (Obviously we're using the CMF here). This is currently achieved using multiple servers, one with a pubished version of the content, and another where the workflow and editing happens. Pretty standard stuff. - Out of synch publishing. certain pieces of content can be published, regardless of the state of the parent or vice versa. Something like I edit a parent, I edit a child, I want to edit a child despite the parent being in a unpublishable state, and so on. this gets conciderably more complicated. Said co-worker went through alot of pain to do manage multiple content trees, do tree diff'ing and so on. - Archiving of all these versions of content. - Handling of multilingual content. - more that are too specific to our need to mention here, basically, highly complex workflows and content types. So something has been developped that meets these requirements, and it's complicated as hell. The development side wraps content objects to make them multilingual, there are 3 content trees maintained. In some cases the content types differ on both sites due to workflow requirements and the fact that the publshing side was already being developped. (Developement was disjointed, an unfortunate situation, but couldn't be avoided). So out of all this, I'm really wanting a better way to do this. Althogh it works, it's rather complicated to maintain, and some of it requires changing the way certain things are done when developping content. So the basic theory is: Wouldn't it be great if we could just have a storage system for Zope that is truly revisioned (I will use this term instead of "versions" as not to get mixed up with Zope versions) ??? i.e. A system where a given object would exist twice somehow ... The revision for publishing, and the other revision going through workflow/editing/etc ... This alone would solve many of the requirements above without the need of many servers and publishing/development/pending tree magic. So my first big question is this: Do Zope internals provide enough flexibility to support such a storage system ? A storage system that actually stores, in a basically permanent fashion, the various revisions of an object ? (I don't mean just historie's/undo's, i mean revision controlled objects in the SCM type sense). Can Zope be made to publish an object using one revision of it, while editing another ? Without re-writing the whole thing of course :) Here's what said co-worker (I keep saying that because he deserves credit for what I think is a great idea) came up with: Using Subversion, and it's Python API, as the storage system for Zope! Perceived benefits: - Revisionned objects: Just remember what revision of the object you want published, and use that ... Editing/Workflow and so on can happen on further revisions. At some point the revision to be published gets changed, and voila. - Efficient storage due to the fact it stores only the differences ... - Call back hooks are available in the python API, so there can be notification of changes in the storage, which introduces interesting possiblities for shared storage, ZEO style. I don't know how ZEO works internally, but I know there's the notification system to expire content in the caches of the clients. Does ZODB do the "notification" or is it in the ZEO code layer ? In this case, the storage itself could provide notification. - Full archival of the objects over time, efficiently. - Benefits from subversion's storage with is BDB 4.2 right now ... - Possibility of benefitting from SVN's "cheap copy" mechanism (sort of OO based, references are used until the content changes). - Many others I'm sure ... I've started looking at the ZODB and APE packages to try and get some understanding of how the whole storage interaction works, but it'll take me some time to figure it all out ... So I thought I'd get feedback on the idea first ... Thoughts, comments ? Thanks, Jean-François Doyon Internet Service Development and Systems Support / Développement des services et soutien de systèmes Internet GeoAccess Division / Division GéoAccès Canada Center for Remote Sensing / Centre canadien de télédétection Natural Resources Canada / Ressources naturelles Canada http://atlas.gc.ca Phone: (613) 992-4902 Fax: (613) 947-2410