[whatwg] Comments on <event-source> and addEventSource()

[Ian Hickson]

On Tue, 27 Feb 2007, Mike Dierken wrote:
>
> > multiple <event-source> elements
>
> I think it'll happen - maybe not a hundred sources, but several and 
> probably all from the same server host. I don't have any feature 
> requests other than multiple sources. My point was just to point out 
> that this is an area of complexity. As if it weren't already obvious...

Could you explain what the expected use case would be? I don't really 
understand why one would have more than one event source per server.


> > > I suggest using onMessage rather than onEvent
> > 
> > Agreed. I've changed the spec appropriately.
>
> Thanks. Just curious - why all lower case? Is that the convention?

Yeah.


> > > 2) format and definition of event streams
> > >
> > > This section indicates that client should re-open connections after 
> > > a small delay if they were closed in a successful situation. This 
> > > section should consider persistent connections (i.e. keep-alive) and 
> > > distinguish reply-level response codes from connection-level 
> > > operations.
> > 
> > The section seems, to me at least, to clearly indicate that it 
> > operates at the HTTP level (or equivalent in other protocol stacks). 
> > Could you elaborate on what you mean?
>
> I recall thinking about the phrasing talked about closing the connection 
> after receiving a block of data. If using the HTTP you wouldn't always 
> close the connection, but would just re-use the connection and submit a 
> new request. That was what I meant by separating message 
> request/response processing from connection open/close operations.

Oh, you mean at the HTTP level with connection keep-alive, as opposed to 
individual messages during a stream of events in an event source?


> > > For example, rather than saying "HTTP 200 OK responses with the 
> > > right MIME type, however, should, when closed, be reopened after a 
> > > small delay.", it may be better to say something like "The retrieval 
> > > of an event-source that completes successfully (it has the correct 
> > > content-type and an HTTP 200 OK response status code) should be 
> > > tried again after a short delay."
> > 
> > I don't understand the difference. Could you explain? Thanks.
>
> Well, responses aren't closed or opened, connections are. So it seemed 
> that you were suggesting that the connection should be closed after 
> every successful retrieval of messages.

Oh, I see what you're saying. I've fixed the spec to be clearer on this.
Let me know if it's still a problem.


> > > In addition, the client should continue to obey the appropriate 
> > > cache-control response headers - this allows the server to 
> > > dynamically influence the interval that the client retrieves future 
> > > events (beyond a static value placed in other attributes on the 
> > > event-source element). This would be useful in the HTTP 204 No 
> > > Content situation described in this section as well.
> > 
> > Well we definitely don't want to honour any headers that say to cache 
> > the data for 200 OK responses with the MIME type used for event stuff 
> > -- in those cases, a cached response would just cause the events to 
> > all replay instantly. I agree that everything else (including 204s)  
> > should honour caching, though, and have fixed the spec appropriately.
>
> Why do you think replaying messages is not what the application was 
> designed to do? I really don't think the content-type response header 
> should override caching - application designers should be able to decide 
> how they want things to work. This is a fairly subtle and tricky area, 
> and my experiments with browser based messages apps actually do benefit 
> from replaying messages from the cache. Partly this is due to a block of 
> messages having a link to the next block of messages, and the client 
> maintaining how far it has gone. Anyway, I don't think we should mandate 
> no caching.

I really don't understand why you would ever want caching. Could you give 
a concrete example?

In my experience, authors have all kinds of trouble with caching and end 
up in these situations putting about six different header lines in a kind 
of magic incantation or prayer to stop caching. It seems like if we can 
bypass the problem by explicitly saying that this won't be cached, we have 
a net win.


> > Second, as it is intended that this work by triggring DOM events, the 
> > framing will automatically have to be based around a DOM event 
> > structure, with any payload encoded as part of that. So allowing 
> > explicit support for other types would not stop the top-level data 
> > from having to include DOM event information.
>
> I really don't understand why the format on the wire /must/ be based 
> around DOM event structure. In fact I strongly disagree. Educate me!

Well, it doesn't have to be, I guess. It's just that we're creating DOM 
events, so it seems like DOM events are a useful thing to spawn. We could 
simplify it down to just blocks of text with blank lines separating them, 
but then you couldn't cause the UA to target events at arbitrary elements, 
or have various types of events be spawned, without a special library on 
the receiving end.

Why should we _not_ use DOM events?


> > > For each message, the WhatWG event-source definition introduces 
> > > specific names used for controlling routing to event handlers but it 
> > > seems trivially easy to define an approach that isn't specific to 
> > > this new syntax. Specifically, the Event and Target names could be 
> > > replaced.
> > 
> > What would be the benefit of this?
>
> The benefit would be in not creating an application specific protocol, 
> which would result in the protocol being usable by other applications 
> and more long lived considering that applications come and go.

If someone wants to make a more generic system, it'd be trivial to do so 
-- I mean, this isn't a complicated system. :-)

But the idea here is really to integrate with the existing HTML/DOM 
mechanisms, which includes being able to target events at arbitrary 
elements, change bubbling behaviour, etc. Without integration with 
HTML/DOM, we would lose all that.


> > > My proposal is to define the each message in the event streams to be 
> > > similar to a request, except that no possibility of a response from 
> > > the client exists. This provides for each message to have a URI that 
> > > indicates it's target and a method that indicates the event type 
> > > (post/put/delete).
> > 
> > That seems way, way more complicated. What's the benefit of this?
>
> More general purpose and in the hands of the application developer. At 
> least, that's my guess.

I'd rather we stay very simple unless there are very good reasons not to.


> > > The situations to consider are when the user manually refreshes the 
> > > page and when the retrieval of the event stream completes 
> > > successfully. When the user manually refreshes the page, the src= 
> > > attribute will be the same as when the page was previously 
> > > retrieved, but should the events be the same as previously 
> > > retrieved, or should they be messages from that moment forward?
> > 
> > That probably depends on the exact semantics of the Web app. If the 
> > app is a ticker, then no, you just want the new news. If it's... 
> > actually I can't come up with a time where you'd want to see old 
> > events.
>
> My sample app is a chat-style application and if the page is refreshed, 
> the user probably would like to see the same messages that were just 
> being displayed, rather than a blank chat panel. I think web app 
> developers should have enough flexibility to easily choose how it works, 
> hopefully without requiring dynamically generated pages.

For a chat application you wouldn't want to send all the messages every 
time -- that would VERY quickly become unscalable. Some of the IRC chat 
channels I'm in today get tens of thousands of lines per _day_, if such a 
system ran unbounded, then after a few months you'd be downloading 
hundreds of megabytes of events each time you loaded the page.

If you want to show events of the past few minutes, or something like 
that, a server-side system can include such events at the start of the 
feed, certainly. But I don't see that you'd want to see the events from 
the previous page load itself. If anything, if you're reloading the page 
it's to get rid of the existing content, no?


> > I can see cases (e.g. games) where you'd want all events since the 
> > page was generated, to make sure the game state since then can be 
> > represented -- but that's easy enough, two techniques would be first 
> > to include a generation number in the URI, and second to make the 
> > first event sent back be a complete update of the current state.
>
> Yes, the first techniques require the server to dynamically generate the 
> URI on a per-client basis. I think.

Certainly. I'd fully expect this to be the case. I don't see how this 
differs from the case you give.


Thanks again for your input! Please do keep it coming. :-)

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