Bill de hÓra wrote: > the problem is managing the stream buffer off the wire for a > protocol model that has no underlying concept of an octet frame. > I've written enough XMPP code to understand why the BEEP/MIME crowd > might frown at it Framing is, in fact, an exceptionally important issue. Fortunately, HTTP offers us some framing capability in the form of chunked delivery. This is much more light weight than what BEEP provides since HTTP assumes TCP/IP as a transport layer while BEEP did not. The HTTP chunked delivery method would be vastly superior to the suggestions for doing thing like including form-feeds or sequences of nulls as entry boundary markers. If you accept a simple rule that says that you will insert HTTP chunk length markers between each entry sent in a "never-ending" Atom file, you get something like the feed I show below. Simply strip out the chunk length data prior to stuffing data into your XML parser. If an entry appears to continue beyond a chunk boundary, discard that entry and continue by reading the next chunk.
See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 for more information on this method. Note that RFC2616 says: "All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding,..." Note: the chunk lengths are not "correct" in the following example. GET /never-ending-feed.xml HTTP/1.1 HTTP/1.1 200 OK Date: Fri Apr 8 17:41:11 2005 Server: FeedMesh/0.1 Connection: close Transfer-Encoding: chunked Content-Type: application/xml; charset=utf-8 ab <?xml version="1.0" encoding="utf-8"?> <feed ...> ... a8 <entry> ... </entry> 93 <entry> ... </entry> And so forth until finally you get a </feed>, the connection closes, or you close the connection. This is simple, requires no new specifications and provides for robust error recovery in that broken entries can be easily detected and discarded. bob wyman