Something like asynchronous XML-RPC possible?

[Will Stuyvesant]

[Laura Creighton]

> > In this case, it might be well to implement an 'it is easier to get
> > forgiveness than permission' policy. 'Convincing the boss that this is
> > a bad idea' is a better plan than 'doing it anyway even though it is
> > a bad plan because it is too hard to explain this to the boss'.  This 
> > is
> > due to the difficulty of 'doing it anyway' regardless of the difficulty
> > of 'explaining to the boss'.


[Stuart Bishop]

> And if you havn't already guessed, I don't think that there are any
> RPC mechanisms that use UDP as their transport protocol. RPC mechanisms
> are usually designed so they can return a result, which is not what UDP
> is good at. So you'll have to write your own and make the square peg
> fit the round hole.

Thank you and Laura and others for your comments and all.  Ammunition
for my next meeting :)

I can think of one argument they will confront me with I do not have a
good answer for.  It is the "blocking caller" or "inefficient thread
creation" thing.   As Stuart guessed, the application is indeed sort
of realtime, they want the caller to continue processing *immediately*
after sending the event to the server.  The prototype I have now does
send an event by means of an XML-RPC call in a separately created
thread (just using pythons' nice ``thread.start_new()``) because it
*has* to receive a return value from the server even though it will
never look at it.  If they say that creating a thread for this is
highly inefficient and a wrong design, what should my answer be?

Stuarts' "industry standard" arguments are very nice, I expect they
will help a lot in deciding in favor of TCP and XML-RPC and HTTP(S)
and "doing what everybody does", which would be much easier for me :)