W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [EventSource] feedback from implementors

From: Per-Erik Brodin <per-erik.brodin@ericsson.com>
Date: Tue, 22 Sep 2009 11:05:26 +0200
Message-ID: <4AB89356.60909@ericsson.com>
To: Anne van Kesteren <annevk@opera.com>
CC: "Michael A. Puls II" <shadow2531@gmail.com>, public-webapps@w3.org
Anne van Kesteren wrote:
> On Mon, 21 Sep 2009 17:39:14 +0200, Per-Erik Brodin wrote:
>> So what you are saying is that "\r\n" will always be a Windows line
>> ending and never a Mac line ending followed by a Unix line ending?
> That's what should happen as that would be consistent with other text 
> formats, e.g. text/html. I guess this should be stated below the ABNF or 
> the ABNF should be rewritten to a more parser/state-like thingy.

I'm envisioning a scenario where event stream data is aggregated from
various sources, and done so improperly so that multiple different line
endings end up in the stream. For example, appending a carriage return
to a string that is already ending with carriage return produces a
different result than appending a line feed to the same string. Since
it's a new format being defined, why not make it clean and simple?

Consider the following example:
print "data: hello\r";
print "data: world\r";
print "\n";  # dispatch!

>> Keep in mind that we are parsing a continuous stream where data arrives
>> in chunks. It is entirely possible for a "\r\n" pair to be split up
>> between two chunks which could be handled by either 1) dispatching an
>> event immediately when receiving a carriage return and then upon
>> reception of the next chunk "remember" that the last character in the
>> previous chunk was a carriage return and discard the first character if
>> it happens to be line feed, or 2) not dispatching an event until the
>> next character after carriage return has been received which could lead
>> to delays in event dispatch. Both these options are far from ideal.
> The first option should not be too hard to implement right? Just a 
> simple state variable in the tokenizer.
My point was not that it would be particularly hard to implement.

Per-Erik Brodin
Ericsson Research
Received on Tuesday, 22 September 2009 09:08:37 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC