Bob Wyman wrote: > Aristotle Pagaltzis wrote: > >>I wonder how you would make sure that the document is >>well-formed. Since the stream never actually ends and there >>is no way for a client to signal an intent to close the connection, >>the <feed> at the top would never actually be accompanied by a >></feed> at the bottom. > > This is a problem which has become well understood in the use and > implementation of the XMPP/Jabber protocols which are based on streaming > XML.
It is: every XMPP server has a hack to deal with it ;) > Basically, what you do is consider the open tag to have a virtual > closure and use it primarily as a carrier of stream metadata. In XMPP > terminology, your code works at picking "stanzas" out of the stream that can > be parsed successfully or unsuccessfully on their own. In an Atom stream, > the processor would consider each atom:entry to be a parseable atomic unit. How XMPP does that opening stanza thing and then proceeds to not close it is not a design to be emulated (imvho). The opening stanza should arrived and be closed. >>If you accept that the stream can never be a complete >>well-formed document, is there any reason not to simply send a >>stream of concatenated Atom Entry Documents? >>That would seem like the absolute simplest solution. > > You could certainly do that, however, you will inevitably want to > pass across some stream oriented metadata and you'll eventually realize that > much of it is stuff that you can map into an Atom Feed. (i.e. "created > date", unique stream id, stream title, etc.). Since we're all in the process > of learning how to deal with atom:feed elements anyway, why not just reuse > what we've got instead of inventing something new. In the Atom case, I don't see why you need to keep the atom:feed open. Just send it once and then send entries in the raw. > A rather nice side effect of forming the stream as an atom feed is > the simple fact that a "log" of the stream can be written to disk as a > well-formed Atom file. Thus, the same tools that you usually use to parse > Atom files can be used to parse the log of the stream. It is nice to be able > to reuse tools in this way... (Note: At PubSub, the atom files that we serve > to people are, in essence, just slightly stripped logs of the proto-"Atom > over XMPP" streams that they would have received if they had been listening > with that protocol. In our clients we can use the same parser for the stream > as we do for atom files. It works out nicely and elegantly.) For high load scenarios using Atom/XMPP to decouple the atom processing from xmpp stream handling you can use the log you're talking about as a poor-man's message queue. cheers Bill
