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
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
