Something like asynchronous XML-RPC possible?
hwlgw at hotmail.com
Sat Jan 25 12:36:37 CET 2003
> > 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'.
> 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 :)
More information about the Python-list