"Christopher G. Petrilli" wrote:

On Mon, Dec 07, 1998 at 09:43:26AM -0800, David Ascher wrote:

...

[ The idea of exporting databases, etc ]

Right -- the other reason is that I do my editing on a server to which I have very good connectivity, but which isn't available to the world. It's my own staging area. The manage_export hack (or a non-hack replacement) should do the job in the future. Thanks

I'm going to prove I really have no life to Paul, but... I was just thinking of this same problem last night in the shower...

Let's work with this:

zope_a - Internal development/testbed zope_b - Production/consumer side

What I'm imagining is that on zope_a you create an object (RemotePublisherDestination) that represents zope_b, and on zope_b you create a object (RemotaePublisherSource) that represents zope_a. Each of these would have a shared secret associated with them for authentication (this could be extended to more trusted forms later).

Now, Jane works on her website ideas on zope_a, trying ideas, blowing it up, using Versioning to try things, commit and revoke them, and when she's done with the whole package, she tags the tree to publish, clicks a button, and automagically, the whole thing is encapsulated in a package (marshalled, etc) that is then shipped over to RemoatePublisherDestination via a secure channel.

Once the package is there, the zope_b site would examine it, and then commit it into the POS as a version. This allows to examination to make sure that all the Acquisition tricks are working correctly, and not broken, and can be commited as a whole thing.

Why is this useful? Overtime, I'd like to be able to run a Zope server at my house that I work on things with, and then move that up to the T1 attached one when I'm done. It's just too slow otherwise. Also, it would be helpful in the case of ISPs, etc., who could let their customers break things on their own sites before working interactively with teh real thing---performance and all.

I agree that this could be useful and is probably doable, but I suspect that the details could mount pretty quickly. It would be alot easier if the objects modified on the development site were *never* modified on the production site.

What's wrong? - Acquisition problems could get weird

Maybe, but not so bad if the two sites are sufficiently in sync.

- Security is a BIG concern

Yes, this has to be done carefully.

- Does this defeat the point of versioning (*)

I don't think so.

- Lots of other things I'm sure others will point out

* - I see versioning as a way to play with ideas in a framework that can be undone trivially, show them to others,etc, without breaking the starting point.

What do you mean by "versioning"? Do you mean undo? Undo is primarily there to make it easy to recover from mistakes. Sessions (soon to be renamed "versions", aka long-running-transactions) provide an even better way to do this.

It's not quite a VC system, which is a totally different question, no?

Right. It's *not* a VC system, although there are some similarities.

One of the neat things that Illustra had (a OO-Relational database) is the concept of time-travel. You could see the database through a time-point.

BoboPOS/SimpleDB was designed to support this sort of thing, although we've never really used it. There are API's there, although there since they haven't been used, I don't know if they still work. I could imagine having Zope 2 feature that allowed you to have a read-only view of some past version of a web site. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.