W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Value of Server-Sent Events

From: Michael Nordman <michaeln@google.com>
Date: Sat, 24 Oct 2009 15:06:16 -0700
Message-ID: <fa2eab050910241506m1c638709va414f949ffcd4a85@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
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.   `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 24 October 2009 22:06:51 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC