* Bill de hÓra <[EMAIL PROTECTED]> [2005-08-22 21:45]: > ... which are cute. I forget I didn't have an opening tag, or a > buffer for the entry. Oh wait, I do ;)
Sure. I didn’t say it was impossible. I was just saying that you have to do more than scan the stream for the sequence “</entry>”. > You already have an XML parser, that's not the problem; The point is that if you get broken XML at some point, the parser may be left in a state where it never closes an entry. Using an illegal-in-XML character allows resynching without reconnecting to the stream. > [Incidentally this is a non-problem for APP because we're piggy > backing on HTTP octets...] Which Fat Pings are doing as well… > 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. Purely for the resynchronization aspect. If you believe that it’s not an issue, then sure, there’s a lot less difference between the two options. * Martin Duerst <[EMAIL PROTECTED]> [2005-08-23 05:10]: > Well, modulo character encoding issues, that is. An FF will > look differently in UTF-16 than in ASCII-based encodings. Depends on whether you specify a single encoding for all entries at the HTTP level or not. For this application, I would do just that, in which case, as a bonus, non-UTF-8 streams would get to avoid resending the XML preamble over and over and over. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
