> I'd rather have the stability of a full-blown, maintained servlet > engine; XML-RPC's spec makes perfomant implementations difficult, > anyhow. We avoid doing performance-critical operations over XML-RPC. In > the future, we will be using more and more Spread > <http://www.spread.org/>, perhaps eventually via JMS > <http://jms4spread.tigris.org/>. We may install the XmlRpcServer as the > RPC layer to use over Spread or JMS. --
Interesting - thanks for the links. I'll take a look Performance wise, maybe our app is peculiar, but for us XML/RPC absolutely flies. We use it for a variety of things, but one aspect is remote log and stats monitoring - which generates a very high rate/volume, of short to medium size (http payload wise) xml/rpc calls. Once we got keep alive figured, xml/rpc beat the daylights out of most other things we tried - direct socket level, binary messaging was about the only thing to beat it, and then not by enough to make the loss of flexibility worthwhile. -- Rob SoftSell Business Systems, Ltd. ' testing solutions for a changing world ' +44 (20) 7488 3470 www.softsell.com [EMAIL PROTECTED]
