Hacker News Reader

Sadly these shims require a per-client queue to ensure message delivery, as events will otherwise be lost during reconnections.

View on HN

Really you should have a queue anyway to account for those on less reliable connections (mobile, satellite, comcast)

EventSource natively supports this via the "Last-Event-ID" header (and can also be used by a shim to ensure it gets messages it missed). And in the case of a room style app you probably already have a room history that can be used to provide this data.

I'm not sure I'm following you. How does this differ from native EventSource?

EventSource sends all events over a single connection which it keeps open indefinitely. This shim receives a single event and then reconnects. In that window there is a period where there will be no connection to send events over, so they will be lost without a queue.

Edit: actually this looks to be a lot more sophisticated than the other shims i havr looked at and does indeed behave more like eventsource. Good job!

Ah, you're suggesting that the shims use long-polling. I don't think that's the case though. If I understand the library correctly, it really is keeping a connection open, so it's really very similar to the way EventSource works.

Addition: Verified. It doesn't disconnect between events (not long-polling).

Reply on news.ycombinator.com