OK, the following is the case:

The setup is for functions dispatching either locally or via XML-RPC.
At the moment, the mechanism I use is to detect locality is flawed and
thus doesn't work well. So I have local XML-RPC calls where I could
have global ones. But.

1. I need that possibility for testing the XML-RPC setup. I cannot set
up multiple instances for every cheap test. At least I shouldn't have
to. The very important reason, however, is:
2. This is a generic call dispatcher. It is used, for example, for
object name resolution in a widely deployed system. So, what could
happen and couldn't happen locally is this:

1. Server1 dispatcher calls, via XML-RPC, Server2.
2. Server2 dispatcher calls Server1, which does something locally
(same communication management object as the dispatcher, maybe another
local call) and then returns

This is the same problem spread out over two servers, where locality
isn't possible anymore. The call from Server1 to Server2 must be made
via XML-RPC and I cannot exclude Server2 calling Server1 back.

Does this make it a little more of a real problem?


2005/12/12, Alan Milligan <[EMAIL PROTECTED]>:
> Hash: SHA1
> Jan-Ole Esleben wrote:
> >>It really *is* in your interests to ensure a single request completes
> >>all your functional requirements ;)
> >
> >
> > That's not possible unfortunately. The design of the system is rather
> > complex, and unalterable in this respect. However, it is not true that
> > it is usually possible to fulfil this requirement. What of programs
> > running on an operating system that call other programs via that
> > operating system?
> >
> I don't believe you.
> You have a client application calling your Zope server's  bla()
> function.  It can do this either by HTTP or XML-RPC by choosing the
> appropriate Content-Type.
> You've chosen to implement this interface by making other XML-RPC calls
> to the same server to complete the task.  This is both unnecessary and
> bad.  Unnecessary because you're doing an RPC when you've got all you
> need in local memory.  This is bad because you're introducing the
> additional overhead of setting up said RPC.  Worse, you're now
> responsible for your own transaction management because you've split the
> task across multiple ZODB connections.
> You need to think about the *correct* way to write your bla() function.
>  In doing this, you want to be able to take advantage of the automatic
> rollback facilities of Zope by keeping all of this in one transaction,
> which will also avoid your initial problem of conflict errors.
> Alan
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> iD8DBQFDnNZcCfroLk4EZpkRArTDAJ96TGwDy047D09jkmRNbGyD7e+3QgCg0aNZ
> lLo0znXi4qvXr5j4SseH2k8=
> =hu4V
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to