firehoseio/firehose

Use Server-Sent Events like semantics

bradgessler opened this issue · 3 comments

bradgessler commented

According to http://caniuse.com/eventsource more browsers support Server-Sent Events to warrant their consideration as a transport for Firehose.

Change the Last-Message-Sequence client header to Last-Event-ID to support more like semantics in anticipation of an SSE Firehose transport. Also change all instances of "last message sequence" variable names in JS and Ruby to "last event id".

We should release this in two pieces:

  1. Make Firehose 1.x series branch support both headers with a deprecation warning for the Last-Message-Sequence header.
  2. Release a 2.x branch that removes Last-Message-Sequence and only has a Last-Event-ID header.
thoughtless commented

I believe @steel looked into SSE back in the early days of Firehose. Perhaps he has some comments about future support. I have heard there are JavaScript-only polyfills for SSE.

I am a little bit concerned using an HTTP header in our long polling that is already reserved for SSE. I understand that long polling and SSE are mutually exclusive so there isn't a direct opportunity for a conflict. However, I just wanted to bring it up as a point to consider.

bradgessler commented

Good point. We could go with X-Firehose-Last-Event-ID for the HTTP Long Polling transport.

bradgessler commented

I'm closing this issue because I think Last-Event-ID is less clear than Last-Event-Sequence for purposes of Firehose, especially since we've implemented dropped message support in #52. The term sequence makes it more apparent that a dropped message is something that's not contiguous in the sequence. An event id is much less clear on that front.