* Henri Sivonen [EMAIL PROTECTED] [2005-08-23 08:45]:
On Aug 23, 2005, at 07:27, A. Pagaltzis wrote:
I still dislike the idea of a “virtual closing tag” – it
ain’t 1995 anymore, after all.
You seem to be thinking that an XML parser needs to consider
the whole document before reporting
At 22:58 05/08/23, Antone Roundy wrote:
On Monday, August 22, 2005, at 09:54 PM, A. Pagaltzis wrote:
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.
Of course, if you do that, you
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
On Aug 23, 2005, at 07:27, A. Pagaltzis wrote:
I still dislike the idea of a “virtual closing tag” – it ain’t
1995 anymore, after all.
You seem to be thinking that an XML parser needs to consider the whole
document before reporting data to the app. This is not the case.
If you have a
Tim Bray wrote:
On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote:
Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a
unique API.
Ahh, I had thought this was a more dedicated ping traffic stream. The
* Tim Bray wrote:
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature and further
processing would be
On Monday, August 22, 2005, at 09:54 PM, A. Pagaltzis wrote:
* 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
--On August 23, 2005 9:40:44 AM +0300 Henri Sivonen [EMAIL PROTECTED] wrote:
There's nothing in the XML spec requiring the app to throw away the data
structures it has already built when the parser reports the error.
There is also nothing requiring it. It is optional. The only
reqired
On 23 Aug 2005, at 2:57 pm, Bjoern Hoehrmann wrote:
No. See, http://www.w3.org/TR/REC-xml/#sec-terminology, under fatal
error. -Tim
Yes, exactly what I wrote...
the XML processor must report the error to the application and that the
processor is not required by the XML specification to
* Graham wrote:
the XML processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature and further
processing would be implementation-defined
vs
Once a fatal error is detected,
On Aug 23, 2005, at 6:57 AM, Bjoern Hoehrmann wrote:
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional
On Aug 22, 2005, at 9:27 PM, A. Pagaltzis wrote:
It's got another advantage. You connect and ask for the feed.
You get
feed xmlns=http://www.w3.org/2005/Atom;
... goes on forever
and none of the entry documents need to redeclare the Atom
namespace, which saves quite a few
On Aug 22, 2005, at 9:56 PM, Bjoern Hoehrmann wrote:
If you encounter a busted tag on the Nth entry, per the XML spec
that's a fatal error and you can't process any more.
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and
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
On 8/22/05, Sam Ruby [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a unique API.
Ahh, I had
--On August 22, 2005 12:36:17 AM -0400 Sam Ruby [EMAIL PROTECTED] wrote:
With a HTTP client library and SAX, the absolute simplest solution is
what Bob is describing: a single document that never completes.
Except that an endless document can't be legal XML, because XML requires
the root
* Walter Underwood [EMAIL PROTECTED] [2005-08-22 18:35]:
The standard trick here is to use a sequence of small docs,
separated by ASCII form-feed characters. That character is not
legal within an XML document, so it allows the stream to
resyncronize on that character.
Ooh! I like this –
Walter Underwood wrote:
The standard trick here is to use a sequence of small docs, separated
by ASCII form-feed characters. That character is not legal within an
XML document, so it allows the stream to resyncronize on that character.
Besides, form-feed actually has almost the right
On 8/22/05, James M Snell [EMAIL PROTECTED] wrote:
+1.. this seems a very elegant solution.
+1.
Indeed both solutions, the never ending feed, and the FF separated
entries both have their advantages. The FF separated stream
has the advantage of being able to synchronize mid-stream. The
never
Yep; an existance proof is server push, which is very similar (but
not XML-based);
http://wp.netscape.com/assist/net_sites/pushpull.html
On 21/08/2005, at 9:36 PM, Sam Ruby wrote:
A. Pagaltzis wrote:
* Bob Wyman [EMAIL PROTECTED] [2005-08-22 01:05]:
What do you think? Is there any
Just as a data point, this should become less of a problem as event-
loop based HTTP implementations become more popular; with them, the
number of connections you can hold open is only practically limited
by available memory (to keep fairly small amounts of connection-
specific state).
--On August 22, 2005 2:01:45 PM -0400 Joe Gregorio [EMAIL PROTECTED] wrote:
Interestingly enough the FF separated entries method would also work
when storing a large quantity of entries in a single flat file where
appending an entry needs to be fast.
The original application was logfiles in
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
]]
...
Just out of interest, how well does any of this work with caches and
proxies?
Graham
On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote:
Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a
unique API.
Ahh, I had thought this was a more dedicated ping traffic stream. The
never ending Atom
Justin Fletcher wrote:
I'm a little confused by all this discussion of never-ending XML
documents, mainly because my understanding is that without the
well-formedness checks the content might as well be free form, and the
elements within the document may rely on parts that have 'yet to
On 8/22/05, Justin Fletcher [EMAIL PROTECTED] wrote:
On Mon, 22 Aug 2005, Tim Bray wrote:
On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote:
Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a unique
At 02:15 05/08/23, A. Pagaltzis wrote:
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
--On August 23, 2005 12:01:11 PM +0900 Martin Duerst [EMAIL PROTECTED] wrote:
Well, modulo character encoding issues, that is. An FF will
look differently in UTF-16 than in ASCII-based encodings.
Fine. Use two NULs. That is either one illegal UTF-16(BE or LE) character
or two illegal
* 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
* Tim Bray [EMAIL PROTECTED] [2005-08-23 02:35]:
It's got another advantage. You connect and ask for the feed.
You get
feed xmlns=http://www.w3.org/2005/Atom;
... goes on forever
and none of the entry documents need to redeclare the Atom
namespace, which saves quite a few
On Mon, 22 Aug 2005, James M Snell wrote:
Justin Fletcher wrote:
I'm a little confused by all this discussion of never-ending XML documents,
mainly because my understanding is that without the well-formedness checks
the content might as well be free form, and the elements within the
* Tim Bray wrote:
If you encounter a busted tag on the Nth entry, per the XML spec
that's a fatal error and you can't process any more.
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by
The subject of Fat Pings
or full content streaming from blogs has come up on the FeedMesh list and in a proposal by Brad
Fitzpatrick of LiveJournal. Ive responded to the FeedMesh list
suggesting that the best way to move forward is to simply use Atom feeds rather
than invent new formats.
Joe Gregorio wrote:
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
This would be an excellent idea if what we were talking about was a
low volume site. However, a site like LiveJournal generates hundreds of
updates per minute. Right now, on a Sunday evening, they are
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.
On 8/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
This would be an excellent idea if what we were talking about was a
low volume site. However, a site like LiveJournal generates hundreds of
updates per
Bob Wyman wrote:
Joe Gregorio wrote:
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
This would be an excellent idea if what we were talking about was a
low volume site. However, a site like LiveJournal generates hundreds of
updates per minute. Right now, on a
* Bob Wyman [EMAIL PROTECTED] [2005-08-22 04:00]:
Basically, what you do is consider the open tag to have a
virtual closure and use it primarily as a carrier of stream
metadata.
Shades of SGML…
You could certainly do that, however, you will inevitably want
to pass across some stream
Joe Gregorio wrote:
Why can't you keep that socket open, that is the default
behavior for HTTP 1.1.
In some applications, HTTP 1.1 will work just fine. However, HTTP
doesn't add much to the high volume case. It also costs a great deal. For
instance, every POST requires a response. This
Aristotle Pagaltzis wrote:
Shades of SGML.
No! No! Not that! :-)
He continues with:
... many good points
Basically, there are many really easy ways that one can handle
streams of Atom entries. You could prepend an empty feed to the head of the
stream, you could use
* Bob Wyman [EMAIL PROTECTED] [2005-08-22 05:25]:
If Atom provides all we need, lets not do something else unless
there is a *very* good argument to do so.
I’m not inventing anything. Atom Entry Documents are part of the
spec and Atom Feed Documents may legally be empty.
And a consumer of a
Bob Wyman wrote:
Basically, there are many really easy ways that one can handle
streams of Atom entries. You could prepend an empty feed to the head of the
stream, you could use virtual end-tags, you could just send entries and
rely on the receiver to wrap them up as required, etc...
A. Pagaltzis wrote:
* Bob Wyman [EMAIL PROTECTED] [2005-08-22 01:05]:
What do you think? Is there any conceptual problem with
streaming basic Atom over TCP/IP, HTTP continuous sessions
(probably using chunked content) etc.?
I wonder how you would make sure that the document is
well-formed.
Joe Gregorio wrote:
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a unique API.
I can, and have, accessed the LiveJournal stream from behind
* Sam Ruby [EMAIL PROTECTED] [2005-08-22 06:45]:
SAX is a popular API for dealing with streaming XML (and there
are a number of pull parsing APIs too).
Of course – using a DOM parser is impossible with either approach
anyway.
With a HTTP client library and SAX, the absolute simplest
46 matches
Mail list logo
