Something like asynchronous XML-RPC possible?

[Will Stuyvesant]

[Irmen de Jong]
>     >> How "realtime" is "sort of realtime"?  Are you on a fast enough,
>     >> lightly loaded enough network?
>  
>     Irmen> Interesting. Not to show off, but for comparison, I just did a
>     Irmen> quick test with Pyro....

[Skip Montanaro]
> 
> I guess we'll have to wait and see what Will's constraints are.  (I have
> Perl clients and a Python server, so XML-RPC is it for me.)
>

I am going to study pyro today, after the family visits are over. 
Sunday huh.  A "hello asynchronous_pyro" example would be nice, you
know the typical usage pattern in a minimum number of lines of code
with comments around?

I learned some things from this thread so I can discuss it at work
tomorrow and settle on the real constraints.  The constraints will be
something like:

1) A caller must be able to continue immediately after issuing an
event: no blocking waiting for a return value

2) Language interoperability.  Preferably using an international
standard.  This is what XML-RPC is good at.  The whole thing will be
based on components written in different languages (Python, C, Java,
...).  For now XML-RPC is even better than SOAP because the SOAP
standard is fluctuating.

3) Speed.  This will always be limited by today's state of the art in
technology, but for example starting a new thread to do a normal
synchronous XML-RPC call will meet strong opposition.

4) Simplicity and elegance of design.  See the desired usage patterns
in one of my earlier posts.  Basically you just want to be able to
turn any class instance object into a "component" that is accessible
via the internet, using only one or two function calls.  The methods
will be assumed to be event handlers that do not return a value, with
the parameters acting as an event.

  I have this usage pattern working for normal synchronous XML-RPC
that *do* have return values.  I also have it with calls from a
freshly created thread, ignoring return values, but that is considered
to be inelegant/inefficient.