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
