Archive of UserLand's first discussion group, started October 5, 1998.

Re: streaming xml-rpc?

Author:Hannes Wallnöfer
Posted:8/23/1999; 12:25:06 PM
Topic:streaming xml-rpc?
Msg #:9806 (In response to 9802)
Prev/Next:9805 / 9807

Right - the "keep alive" concept was what I was trying to get to. You could practically do a "chat" system that way by sending xml-rpc calls to other's clients to display the messages you typed, or run live browser sessions, or tell your Mars rover to turn left...

From what I understand, you want something that could be called asynchronous multi-response XML-RPC: The client sends one request, then the server keeps feeding the client with responses whenever it has something available, resulting in callbacks on the client side for each response part.

The asynchronous part of this has been implemented in Frontier and could probably be implemented on most other platforms. The multi-response part is a bit trickier, but not because of HTTP - an HTTP server can pause sending its response at any time (subject to client time-outs), and since you're just sending one request from the client, the multiple XML-RPC responses would technically be just one big HTTP response. (HTTP keep-alive is only needed to keep the connection alive *between* requests.)

The problem is with XML-RPC itself. According to the XML-RPC spec the server has to send the size of the XML-RPC response with the HTTP headers, so it needs to know it in advance. Without this, it gets very tricky to know where an XML-RPC message ends and another (or, thanks to HTTP keep-alive, a whole new request) starts.

One solution could be to allow for some sort of MIME multipart content type in RPC responses with each part containing its own size in the headers, but that would bring a completely new requirement to RPC implementations (MIME multipart parsing), so at least it's not a short term option.

There are responses to this message:

This page was archived on 6/13/2001; 4:52:03 PM.

© Copyright 1998-2001 UserLand Software, Inc.