Re: [EventSource] feedback from implementors

On Fri, Sep 18, 2009 at 8:37 AM, Per-Erik Brodin
<per-erik.brodin@ericsson.com> wrote:
> 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.

This is a somewhat off-topic post, but I figured people I should
mention it anyway.

We currently don't have any plans for implementing this in Firefox.
The biggest reason is that we simply haven't gotten any requests from
developers to implement this. We also don't think that it provides
enough functionality beyond simply using XMLHttpRequest.

Especially the latter would change if someone wrote up a specification
for how to use EventSource over SMS or similar technologies, since
then it would provide a low-power way to push data for mobile
platforms.

This is not to say that we don't think other vendors should implement
it if they want. I'd in fact encourage it so that we can see if it
turns out to be more popular/useful that we've perceived so far.

/ Jonas

/ Jonas

Received on Monday, 5 October 2009 18:29:18 UTC