* 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 rep
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
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 that
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
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 bytes after th
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 feature.
* 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 de
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
--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 beh
* Antone Roundy <[EMAIL PROTECTED]> [2005-08-23 16:05]:
> Of course, if you do that, you won't be able to keep signatures
> for entries originally published in an encoding other than the
> one you've chosen.
Why is that a concern for a site publishing a stream of its own
users’ posts?
Regards,
-
* 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
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 e
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 traffi
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 docum
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 is
* 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 t
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
documen
* Tim Bray <[EMAIL PROTECTED]> [2005-08-23 02:35]:
> It's got another advantage. You connect and ask for the feed.
> You get
>
> 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
* 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 “”.
> You alrea
--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 cha
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 Aug 22, 2005, at 6:15 PM, Justin Fletcher wrote:
Ah; I misread that in the specification. Thanks. It's just the lack
of well-formedness that is an issue in my head then.
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.
Justin Fletcher wrote:
Ah; I misread that in the specification. Thanks. It's just the lack of
well-formedness that is an issue in my head then.
Hey, that's better than what I can claim. For me, it's usually the lack
of well-formedness in my head that's the issue ;-)
- James
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 inv
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 arrive
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
API.
Ahh, I had thought this was a more dedicated ping traffic
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 documen
Just out of interest, how well does any of this work with caches and
proxies?
Graham
A. Pagaltzis wrote:
> * Bill de hÓra <[EMAIL PROTECTED]> [2005-08-22 19:00]:
>
>>In XMPP, you can reset on seeing ,
>
>
> Really?
Really. And I've even seen the two test cases below...
>
>
>
> Or maybe
>
>
... which are cute. I forget I didn't have an opening tag, or a buffer
f
--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 logfile
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). This
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 an
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
Walter Underwood wrote:
> Except that an endless document can't be legal XML, because XML
> requires the root element to balance. An endless document never closes
> it. So, the endless document cannot be legal Atom. Worse, there
> is no chance for error recovery. One error, and the rest of the
> s
A. Pagaltzis wrote:
* 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.
* Bill de hÓra <[EMAIL PROTECTED]> [2005-08-22 19:00]:
> In XMPP, you can reset on seeing ,
Really?
Or maybe
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 si
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 sema
* 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 –
--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
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
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 at the top would never actually be accompanied by a
>>
* 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
>
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 bot
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
>
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...
* 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
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 "virt
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
* 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
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 S
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
> update
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 at the top would never actually be accompanied by a
> at the bottom.
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 upda
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
-joe
--
Joe Gregoriohttp://bitworking.org
* 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. Since the stream n
54 matches
Mail list logo