search

firehoseio / firehose

Build realtime Ruby web applications. Created by the fine folks at Poll Everywhere.
http://firehose.io/
MIT License
726 stars 72 forks source link

Use Server-Sent Events like semantics #36

Closed bradgessler closed 8 years ago

bradgessler commented 10 years ago

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 10 years ago

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 10 years ago

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

bradgessler commented 8 years ago

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 https://github.com/firehoseio/firehose/issues/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.