Thanks Tres for the reply. It really helps.
I agree transactions are a problem. If SVN fails there is no clear
route to notify the user. On the other hand we merely would use it for
'historic' storage - a one way system for moving objects. As we have
to have a queue anyway, on failure an object should not be removed
from the queue. That allows the administrator to resolve the SVN
problem and rerun the queue.
BTW I think there are two ways to make a queue - through the
filesystem (like the mailer does), or through ZODB - accessing the
queue through XML/RPC on a separate thread. If anyone knows how to use
ZODB from an independent thread outside ZOPE I am all ears. I would
like to drop the XML/RPC.
You made me think of an alternative approach though. I don't know how
you resolved your content repositories, but how about mirroring a site
into a versioned repository in ZODB. When we have a site with objects
we could create a versioned site with versioned objects (inheriting
security per object):
ZODB:
mysite:
objectA
objectB
etc.
mysite_versioned:
objectA_00001
objectA_00002
objectA_00003
objectB_00001
objectB_00002
etc.
An XML/RPC interface could be created to store the versioned objects
offline - as objectA and objectB - through an external command. That
would allow an admin to do that through a CRON job with feedback on
the transaction. It could also purge old objects.
The nice thing is that I can quite easily create a view of older
objects in mysite_versioned (all XML/XSLT with xParrot) and even do a
simple diff, indeed. Recovery is straightforward too.
What do you think?
Pj.
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
