If you're not using a Web browser, there's really no reason to use this format. It's a trivial format. You're much better off defining your own format that does what you need, rather than trying to piggy-back on this Web-specific format.

This particular situation arose out of the limitations of the mobile application lifecycle. A certain web service only supplies current data via Server-Sent Events. You miss out on data that happened before the app was started or while the app was in the background (in the case of apps that do not run in the background). 

To get around this, a caching server can be made available that reads the same data from the web service in real time, and plays back temporal sequences to a client that needs to play catchup. The caching server would need to act in a similar manner to a web browser, reading eventsource data.

Upon waking up (or being launched), the app can ask the caching server what it missed, and then get current information from the original web service. 

A wire level description of the Server-Sent Events specification would be extremely useful for developing a caching service like that. I can think of many more examples (monitoring service, etc), but the one I mentioned is a real life example that is currently being developed.

Please reconsider your resolution to this issue.

Why wouldn't you just change the Web service to expose the data in a more sane form, e.g. over a custom bidirectional TCP protocol that did away with the need for the proxy?

(In reply to Ian 'Hixie' Hickson from comment #3)
> Why wouldn't you just change the Web service to expose the data in a more
> sane form, e.g. over a custom bidirectional TCP protocol that did away with
> the need for the proxy?

There is little value in devolving this conversation down to how we should be engineering our product. Suffice to say given our unique constraints, it is easier for us to adapt to the existing protocol (Server-Sent Events), than it is to add another protocol handler to the existing service. We would love nothing more than to have a simplified protocol to interact with, but that option is not available to us at this time.

The larger issue remains that there are legitimate use cases for understanding the Server-Sent Event protocol at the wire level. A few that I can think of off the top of my head:

* Automated monitoring of customer web interface experience.
* Anyone crazy enough to develop a brand new web browser.
* Some people will simply understand this protocol better from this point of view.

> * Automated monitoring of customer web interface experience.

That's an interesting idea.


> * Anyone crazy enough to develop a brand new web browser.

They would presumably be developing a Web browser, so would need the spec as it is now, not one that doesn't do the API.


> * Some people will simply understand this protocol better from this point of
> view.

The introduction section explains the protocol, I don't think a normative description would help people understand it more than that.


But the idea of having a non-Web client as a way to test a Web service is interesting. However, what would it need to do beyond parsing it? (Parsing is already defined in a manner separate from browsers.) I mean, it's not really clear what it means for a testing framework to be conforming or not. Surely it can just do whatever it wants?

Basically it's just the "dispatch the event" algorithm that's browser-specific, right? Would it address your use case to have the spec instead invoke "the appropriate event-handling hook for the user agent" and have the appropriate one for browsers be the current "dispatch the event" algorithm?

My plan is to do what I describe in comment 6. If that isn't sufficient, please let me know.

Checked in as WHATWG revision r8475.
Check-in comment: Make the EventSource processing model a mite more generic to allow other user agent types to implement this spec.
http://html5.org/tools/web-apps-tracker?from=8474&to=8475