A. Pagaltzis wrote: > * Bill de hÓra <[EMAIL PROTECTED]> [2005-08-22 19:00]: > >>In XMPP, you can reset on seeing </atom:entry>, > > > Really?
Really. And I've even seen the two test cases below... > > <![CDATA[ > </entry> > ]]> > > Or maybe > > <![CDATA[ > <![CDATA[ > </entry> > ]]> ... which are cute. I forget I didn't have an opening tag, or a buffer for the entry. Oh wait, I do ;) > These are probably the only exceptions (I might be missing some, > though), but they’re enough to demonstrate that you will need to > write a parser, even if only a relatively simple one. You already have an XML parser, that's not the problem; 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 - manipulating infosets right on top on sockets make for funky code and isn't my notion of what "bits on the wire" should be ;) [Incidentally this is a non-problem for APP because we're piggy backing on HTTP octets...] > Using a character which is illegal in XML and can never be part > of a well-formed document as a separator is a clever way to avoid > having to do *any* parsing *whatsoever*. You just scan the stream > for the character and start over when you see it, end of story. > No need to keep state or look for patterns or anything else. I see all the +1s, but don't understand why reinventing multi-part MIME with formfeeds as a special case for Atom is more attractive that an infinite list of entries whose closing atom:feed tag never arrives. Still, I think this discussion is valuable: it speaks volumes on the use of XML for wire protocols, especially for the single document school of thought. cheers Bill
