[whatwg] Server-sent events feedback

[Ian Hickson]

On Tue, 12 Oct 2010, ATSUSHI TAKAYAMA wrote:
>
> When processing a line with only "data:", the data buffer will be the 
> empty string and the LF character added at the "process the field" 
> stage. When dispatching the event, the first step "If the data buffer is 
> an empty string, set the data buffer and the event name buffer to the 
> empty string and abort these steps." does not apply here (since we have 
> the LF character, which will be removed in the step 2). So it does fire 
> a MessageEvent with an empty string as the data property.
> 
> I think the steps 1 and 2 of the dispatching should be the other way 
> round.

Why?


On Thu, 14 Oct 2010, ATSUSHI TAKAYAMA wrote:
> On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren <annevk at opera.com> wrote:
> >
> > Why would we not want to dispatch an event where data is the empty 
> > string in this case? I do not think this is an error. (Although 
> > admittedly I once thought it was.)
> 
> Well, in that case the example should be re-written:
> 
> = http://dev.w3.org/html5/eventsource/#event-stream-interpretation
> 
> The following stream fires just one event:
> data
> 
> data
> data
> 
> data:
> 
> The first and last blocks do nothing, since they do not contain any
> actual data (the data buffer remains at the empty string, and so
> nothing gets dispatched). The middle block fires an event with the
> data set to a single newline character.
> 
> = up to here

Oops, fixed. I often forget to updated examples and introductory text, 
that's why I tend to wait until a section is stable before adding them.


> It's slightly out of topic, but what's the idea behind making a line 
> without a semicolon make the whole line the "field"? The 3 out of 4 
> possible "field" names, "event", "id" and "retry" make no sense without 
> the value. Also "data" line without any message seems useless to me, and 
> even if you do want it without a message "data:" does the job.

The idea is just to make the parsing trivial. It's error-handling.


On Thu, 25 Nov 2010, ATSUSHI TAKAYAMA wrote:
> 
> I would say the simpler the rule is, the better.
> So a line without colon should be ignored.

Why is that simpler?

I think one could argue simplicity either way. Either it's simpler because 
you just keep adding to the name until you get to the end up the line or a 
colon, or it's simpler because there are fewer possible error conditions.

The advantage of making a colon-less line be valid is that we can later 
introduce boolean-style flags that don't take a value and they would work 
the same way, but not need a colon.


On Fri, 15 Oct 2010, Nicholas Zakas wrote:
>
> In reading through the spec, it looks like this is legal in the event 
> stream:
> 
> event: foo
> data: bar
> 
> And then processed as:
> 
> >> If the event name buffer is not the empty string but is also not a 
> >> valid event type name, as defined by the DOM Events specification, 
> >> set the data buffer and the event name buffer to the empty string and 
> >> abort these steps.
> 
> If I'm reading this correctly, an event name of "foo" would fail this 
> step in the process and not cause a message event to be fired.

"foo" is a valid event type name. In fact as far as I can tell, DOM3 
Events no longer restricts event type names at all. I've removed that step 
to make it less confusing.


> However, if the event name were for example "click", then this would be 
> okay and the following step would be taken:
> 
> >>If the event name buffer has a value other than the empty string, 
> >>change the type of the newly created event to equal the value of the 
> >>event name buffer.
> 
> A few questions about this:
> 
> 1)  Does this mean that a click event would be fired on the EventSource 
> object, such as that onclick would be called?

Yes.


> 2)  Why the limitation of events only in the DOM Events spec? It seems 
> that most of those events are irrelevant in the context of a non-UI part 
> of the page.

The limitation was on valid event type names, because it used to be that 
you couldn't e.g. use a space in an event type name. This restriction 
seems to have been removed.


> 3)  Assuming I've understood the current spec correctly, what is the use 
> case for named events?

It's so that you can categorise your events, e.g. have a 'stock-up' event 
and a 'stock-down' event, and then use the event registration mechanism to 
hook different event listeners up.


On Mon, 18 Oct 2010, Nicholas Zakas wrote:
>
> When you define an custom event name, this still fires the message event 
> with event.type set to the custom event name.

No, it fires the event with the custem event name. "onmessage" only fires 
for events with the name "message".


On Tue, 19 Oct 2010, Nicholas Zakas wrote:
>
> In the latest draft of Server-Sent Events, the EventSource object 
> upholds the same origin policy for event stream resources. Although CORS 
> is mentioned in the references section, it's not mentioned in the body 
> of the spec, so I was wondering if this has been brought up before?

Yeah, I'm waiting for CORS to be more stable.


On Fri, 12 Nov 2010, Nicholas Zakas wrote:
>
> Just a quick question about the Last-Event-ID header. The spec currently 
> says:
> 
> >>If the event source's last event ID string is not the empty string, 
> >>then a Last-Event-ID HTTP header must be included with the request, 
> >>whose value is the value of the event source's last event ID string, 
> >>encoded as UTF-8.
> 
> Consider the following scenario: a connection is established and one of 
> the events has an id of "foo", so the last event ID of the event source 
> is now "foo". The connection drops and on reconnect, the header 
> Last-Event-ID: foo is sent per the spec. The next stream of events 
> coming through do not have any IDs. The connection is dropped again.
> 
> The question is whether or not Last-Event-ID: foo should be sent a 
> second time? Technically, it is the last event ID of the event source, 
> and the spec never mentions resetting the last event ID outside of an 
> empty "id" field in the stream.

Yes, it should be sent a second time.


On Thu, 2 Dec 2010, Anne van Kesteren wrote:
>
> For fetching EventSource resources treating mailto as if it was a 204 
> does not work as that reestablishes the connection. The result should be 
> more akin a network error of some kind I think. Similarly to how other 
> cross-origin requests fail if CORS is not used. I will add some tests 
> for this.

I've changed the EventSource spec to make 204 abort, along with all other 
2xx codes other than 200 with the right type. I don't know what I was 
thinking there.


On Thu, 2 Dec 2010, Anne van Kesteren wrote:
> 
> javascript, about:blank etc. should also be treated like this, naturally.

javascript: has Content-Type text/html, and about:blank has no 
Content-Type, so those are already handled.


On Thu, 2 Dec 2010, Anne van Kesteren wrote:
>
> Per the EventSource specification URLs are resolved against the "first 
> script". However, implementations -- Opera and Chrome -- appear to 
> resolve URLs in the same way they are resolved for XMLHttpRequest. I.e. 
> against the Document the interface object is associated with.
> 
> That is why this testcase is failing:
> 
> http://tc.labs.opera.com/apis/EventSource/eventsource-constructor-url-multi-window.htm
> 
> It makes some sense to me to resolve URLs in the same way as 
> XMLHttpRequest. Does "first script" really make sense here? I also 
> wonder if "first script" is actually ever used for this. (Did not put 
> time in investigating that for now.)

This should be fixed in the browsers, IMHO. The first script is always 
used in legacy APIs except for XHR, as far as I can tell.

(If I'm wrong, much more should change than EventSource.)


On Fri, 3 Dec 2010, Adam Barth wrote:
>
> First script is the most common thing to use to resolve relative URLs. 
> Some APIs do it differently because, well, the web platform is awesome.  
> I don't think there's any problem with using the interface's document 
> instead in this case.

I haven't changed the spec here, because I really think it makes more 
sense to be consistent with the bulk of the platform here. Let's leave XHR 
as the aberration...

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'