[whatwg] Minor event-source (SSE) modification

We're using SSE as a reliable Server -> Browser streaming mechanism where
the server maintains a message queue per user connection. The server needs
to buffer all messages until it receives an acknowledgment for a given
message (ACK). The server sometimes needs to indicate to the Browser that
the message queue has become too large and the browser should send an ACK as
soon as possible. One way the server can indicate that it needs an ACK is to
end the HTTP Response causing the event-source stream to automatically
reconnect with the "Last-Event-ID" header. We call this an "in-band ACK",
where the server sends a "request for ACK" by ending the HTTP response
(using transfer-encoding chunked and sending the 0 chunk, for instance.)

Normally, a message's latency is  the time it takes to travel from the
server to the browser, or one leg. For in band ACKing, it takes 3 legs to
deliver the next message after an ACK request: 1) Server -> Browser (end of
response), 2) Browser -> Server (new request), 3) Server -> Browser (next
message). A solution to this problem is to make a second concurrent http
request that represents the ACK; this we call an "out-of-band ACK".

Unfortunately, the current Server-sent Events specification provides no way
for a user of the event-source API to know the value of the lastEventId,
thus making it impossible to send an ACK out-of-band. We have two proposals,
either of which can solve this problem.

1) Expose the id attribute on each dispatched event. This allows us to send
out-of-band ACKs as required. The downside is that we would need to extend
the MessageEvent interface.

2) Expose an add/remove EventListener on the event-source dom element that
dispatches whenever the last event id for an event source is changed. The
event generated by a change in the last event id would have that id value as
an attribute, as well as the href for the event source associated with the
id.

We prefer the first solution, but any solution would be good. Any
suggestions for a better solution?


-Michael Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080421/82c16f04/attachment.htm>

Received on Monday, 21 April 2008 16:10:49 UTC