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

Re: [EventSource] feedback from implementors

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 22 Sep 2009 13:25:15 +0200
To: "Per-Erik Brodin" <per-erik.brodin@ericsson.com>
Cc: "Michael A. Puls II" <shadow2531@gmail.com>, public-webapps@w3.org
Message-ID: <op.u0noodhz64w2qv@annevk-t60>
On Tue, 22 Sep 2009 11:05:26 +0200, Per-Erik Brodin  
<per-erik.brodin@ericsson.com> wrote:
> 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!

I'm not very opposed, but given that this is a text/* media type and that  
this is how most text/* media types work (in practice, per some old  
specification only CRLF is a new line) it makes sense to me to keep it  
that way. We could strongly encourage authors to just use \n for the  
reasons you mention or indeed deviate from the standard format.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Tuesday, 22 September 2009 11:40:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT