Re: Value of Server-Sent Events

On Fri, Oct 23, 2009 at 8:45 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Fri, 23 Oct 2009, Michael Nordman wrote:
> >
> > An area that may be worth exploring, that would add to the list things
> > that go beyond syntactic sugar, could be for multiple documents to
> > listen in on the same event-stream backed by the same connection to the
> > server. This could reduce the total number of hanging GET style
> > connections used by an application (spread across multiple pages /
> > workers) on a particular client, and by extension the number of
> > connections seen by the server-side.
>
> The spec technically allows this already, though as written it requires
> sending all the same messages again, so it's not really practical (and
> loses the "don't have to hang on to everything" advantage). It's not clear
> to me how we would know which messages are skippable -- maybe in v2 we can
> add a flag that indicates that this message block should be remembered,
> and another flag to indicate that all previous remembered messages should
> be dropped, or something like that, and when a new page hooks in, if the
> event source supports it, it would just get the saved messages and then
> resume with whatever the next message is.
>

> sending all the same messages again... flag that indicates... remembered

That's certainly not what I had in mind? I'll try to describe more clearly
what I was getting at with a simple contrived use-case. There's nothing
complicated about it.

There's a thermometer somewhere in the world connected to a web application
server. The web application server responds to two HTTP GET requests.

GET /current_temp
A short-lived request that returns a textual response that looks like {
"temp": 22.22, "time": "<HTTP-date>" }.

GET /temp_stream
This one is intended for use with a long-lived hanging GET (ala
event-stream). It returns a temp/time sample once every 60 seconds in the
same json format.

When a page opens the /temp_stream event-stream, it only receives temp/time
samples that occur after its having joined the party. This model wouldn't
work for all event-stream use cases, but for some it would.

How to distinguish which event-streams were "shareable" or not is an
interesting question? Maybe that's most properly a function of the
Content-Type of the event-stream?


> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>