Chris: the errors I get are always ConflictErrors without any usable
tracebacks. I would like to give more information, but it really is
very complex when you go a little deeper and would probably not be
useful. I'll try to describe it a little better anyway:

I have an Object that offers an interface for dispatching methods. It
does so by deciding wether the method's object is on the local server
or not, and depending on that, calls it via XML-RPC or via the ZOPE
context (self). A remote ZOPE server cannot be part of a ZEO backend
because there need to be several (hundred) self sustained servers that
can act on their own when the connection to the others fails (which is
likely rather than possible).

But, as I just realised - in an internet context, isn't it possible
that something like this could happen without even being part of a

One ZOPE server's object, say, "LibraryManager", calls an object in
another ZOPE server, say "UniversityLibrary", via XML-RPC (because it
doesn't even know it's ZOPE). It asks it for a book. The University
Library doesn't have it, but it has a service that looks in all the
libraries it knows and returns any found occurences. Thus, at some
point during that call, it asks the first server's LibraryManager
about the book - again, not even knowing that it is a ZOPE server, via

Should this work, and where does it differ from what I'm doing?

> > The problem is that it isn't my design, and the design is part of a
> > contract. I can't really do anything about that (the major problem is
> > that there will be SOAP components that might even need to be
> > transparently integrated - which completely excludes ZEO).
> Why do you think that?  ZEO is simply a single point of persistence for
> a group of Zope Application Servers.

But what if I don't know which components are ZOPE, and components can
be transparently exchanged?

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to