Re: [EventSource] feedback from implementors

Ian Hickson wrote:
> On Fri, 18 Sep 2009, Per-Erik Brodin wrote:
>  >
>  > When parsing an event stream, allowing carriage return, carriage return
>  > line feed, and line feed to denote line endings introduces unnecessary
>  > ambiguity into the spec. For example, the sequence "\r\r\n\n" could be
>  > interpreted as three or four line endings.
> 
> I've clarified the stream parsing format to define the above strictly as
> three line endings (not counting the end of the line).

That should take care of the ambiguity in stream parsing, but "not
followd by a U+000D CARRIAGE RETURN (LF)" should probably read "not
followed by a U+000A LINE FEED (LF)".

>  > Since the event stream format isn't yet widely established, and I don't
>  > see any compelling arguments why allowing multiple line endings would be
>  > beneficial, I hope that it's not too late to change this.
> 
> Windows and Unix in particular have different default line endings, so I
> think we would be making authors' lives unnecessarily complicated if we
> required a particular kind of line-ending.

Yes, Windows and Unix applications and libraries use different default
line endings and carriage return line feed and a single line feed is
what we currently support. We will update the implementation to also
support a single carriage return.

>  > Another unclarity regards the onmessage attribute listener. Should that
>  > trigger for all events of type MessageEvent or only for events that have
>  > the event type set to "message"?
> 
> The spec explicitly says that 'onmessage' is an 'event handler' with the
> 'corresponding event handler event type' 'message'; this unambiguously
> answers the above question. (You might have to look up the terms 'event
> handler' and 'event handler event type' in HTML5 to make much sense of
> this, admittedly.)

I'm aware of the definitions of 'event handler' and 'event handler event
type' in HTML5. As I've mentioned we did manage to get this right, I'm
just trying to think of places where others could misinterpret the spec.

>  > Also, when calling close on an event source, the spec doesn't say
>  > whether or not an error event should be dispatched, unlike the web
>  > socket specification that says explicitly to fire an event. In my
>  > opinion, an error event should not be dispatched since you may typically
>  > call close from an error event listener in order to cancel a reconnect
>  > in the case where the connection is reset, which would then result in a
>  > second error event being dispatched.
> 
> No error event is dispatched, because it doesn't say to dispatch one.
> Similarly, no 'close' event is dispatched, no 'peanut' event is
> dispatched, and the disk doesn't get reformatted. :-)

I figured the disk doesn't get reformatted because that wouldn't be nice
to users, but are you sure about the peanut event? Seriously though,
sometimes it could be nice to have a "must not ..". Maybe it's not
motivated here.

>  > Maybe it would be useful to have a reconnect/reopen method to enable an
>  > application to reestablish the connection from a previously closed event
>  > source?
> 
> This is explicitly not supported, because we don't want people doing this.
> If the connection ever gets closed, then the site likely has a problem,
> and we do _not_ want to encourage authors to just try to reconnect, since
> that is more likely to make the problem worse than anything else.

You are right, we don't want clients hammering a site that has a
problem. What I had in mind was the problem with intermittent network
errors causing the EventSource to close. Now that the spec says that an
EventSource should automatically try to reconnect on such errors there
is no need for a manual reconnect.

>  > Finally, it could be useful to be able to reset the reconnection time to
>  > the user agent default value by sending the retry field only and leave
>  > out the value similar to how you reset the last event id.
> 
> What's the use case?

Take the stock ticker as an example. When the stock market closes the
server logic knows that there won't be any new events for a number of
hours and so it can send the corresponding reconnection time and close
the connection. If the client is still running by the time the market
opens, it will reconnect, and the server can now reset the reconnection
time to a time that is convenient for the user agent (which is the user
agent default value, unknown to the server).

--
Per-Erik Brodin
Ericsson Research

Received on Thursday, 8 October 2009 12:42:58 UTC