Im not sure about feature creep - but this is definitely UI creep. Some zope objects are already hard to manage without a wide browser window. Does this need to be T-T-W, or is it more appropriate to implement it as external scripts?

I am not sure whether this is the right place, but it would be great to have easy syncronization between Zope servers. Apart from the "classic" ZEO scenario I see another use for this: A couple of people have asked me if Zope-based groupware can be used offline like Lotus Notes. If it was possible to easily synchronize Zope installations, not only in an online scenario like ZEO, but also with machines being temporarily disconnected, this would indeed be possible: A local Zope instance can be installed even on a Notebook computer, so people could work offline. As soon as they reconnect to the web, the local Zope could synchronize with the "master server".

Shane... do you envision the Sync tab to be implemented in a synchroization mechanism independent way? Or will the actual form be provided by the sync implementation as a standard tab? I'm thinking that, for example, with CVS, there are lots of tweaks you'd want to be able to do regarding exactly how the sync is done... a particular tag? a particular date? etc.... I really like the idea of having this as a standard part of Zope. I hope the CVS stuff get's to the point where it can be. It's amazing how much time is required to maintain sanity in a production/development mixed environment like we have with Zope. (Unlike most applications, Zope sites tend to be forever evolving... I think it's a web thing. ;-> )

That's correct. The idea is you'd be able to drop in any number of sync strategies, such as CVS or some kind of Zope->Zope connection. Access to them would automatically be available in the containing folder and all subfolders.

Using synch strategy objects that work with the filesystem implies managing the filesystem through the web, and all of the security risks that that entails. For example, I can't imagine ensuring that my CVS versions of source won't create a hole if different versions are mixed for different source files. I'd say that it's the synch strategy's problem, but this proposal is pushing the implementation into SimpleItem^x... so in addition to considering security risks, you need to consider that you're breaching the implicit firewall between through-the-web and filesystem editing, so there's an attitude change involved. There have always been ways around that, of course, but AFAIK never in so central a place as OFS.

while this looks like another useful & needed tool to let developers work with their own sandboxes effectively, I don't see how it could work with several developers, several ZEO clients, and one ZEO server. Is that way out of scope? Or will cached objects know to look for a synch strategy object?