Chris Withers <chrisw@nipltd.com> writes:
Nitin Borwankar wrote:
So going with ZEO seems like a step in the opposite direction, philosophically and from the point of view of functionality, since ZEO is a number of *servers* working together rather than a number of clients i.e. it's "server++" not "client++" as in Groove.
The difference between servers and clients is in the eye of the beholder ;-)
As I understand the ZEO architecture there is one Zope Storage Server (ZSS) that handles writes and many instantiations of Client Storage (CS) that can handle reads. You would have Groove-like (groovy?) functionality if: 1) The ZODB on one site could consist of CS instantiations for several ZSS servers, each one representing a shared workspace. 2) To be fully buzzword compliant you enabled a peer-to-peer architecture. Thus a ZODB knows it wants workspace A; it looks for one on the net; if it finds one in makes a local CS for A, if not it starts a ZSS. This begs the question: what happens if two ZSS end up being started for the same workspace? I guess Groove must have some means to stop this happening, or some framework for merging changes. 3) You encrypted the synchronisation protocol between the CS's and the ZSS. Thus by adding a Persistent mixin to a Python class and adding a few well placed calls to "get_transaction().commit()", you would allow it to synchronise efficiently and securely with any other Python program on the planet. Such an architecture sounds cool. It might even be useful. --- Alastair