[EventSource] feedback from implementors

We recently landed an implementation of server-sent events in WebKit
(see http://trac.webkit.org/changeset/47323).
As an implementor of the specification, I would like to share my
thoughts on a couple of things that could benefit from clarification,
and a few possible issues.

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. 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. I know that the spec originally said line
feed only and that the additional allowed line endings were added based
on earlier feedback. I prefer line feed only but would be fine with also
allowing carriage return line feed since then in practice line feed
would be end-of-line and any preceding carriage return would just be
discarded.

Looking at the ABNF, I don't see why colon would not be allowed in
any-char but line feed would, so I think that COLON has mistakenly been
disallowed instead of LINE FEED.

In the second example of how to interpret an event stream it is stated
that two empty data lines result in an event being dispatch with data
set to a single newline character. I don't see how this would be
possible given that a newline character should not be added if the data
buffer is empty. If this behavior is desired, one way of achieving it
would be to specify that the data buffer is initially uninitialized and
that data added to the buffer should not be prepended by a newline
character if the buffer is uninitialized.

It is explicitly stated that the URL attribute should return the
(absolute) URL that was passed to the constructor. Does that mean that
it should not change on permanent redirects where the actual URL that
the event source uses when reconnecting is changed? I'm fine with this
even though it will mean that we are keeping the original URL around
just for the sake of this attribute.

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"? When we did the implementation we
interpreted the spec as stating the latter, but that would mean you
would have to use addEventListener when the event field is used to set
an event type/name other than "message". Otherwise you could use a
switch statement on event.type to handle different event types in
onmessage.

Although it might be self-evident, the spec doesn't say that calling
close should cancel a pending reconnect. 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.

In the case of network errors, should the event source "fail the
connection" and not try to reconnect if you temporarily loose
connectivity? When the event source ends up in the CLOSED state it is
pretty much useless and if you want the application to reconnect you
would have to create a new event source and register all event
listeners again. 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?

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.

--
Per-Erik Brodin
Ericsson Research

Received on Saturday, 19 September 2009 15:36:23 UTC