[Bug 8359] New: For Server-Sent Events, add informative language about how this could be implemented using fallback to a push-proxy using OMA Push

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8359

           Summary: For Server-Sent Events, add informative language about
                    how this could be implemented using fallback to a push-
                    proxy using OMA Push
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec proposals
        AssignedTo: dave.null@w3.org
        ReportedBy: robert.ennals@intel.com
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


[I'm not sure I specified the correct component - I couldn't see a component
for Server Sent Events]

This is a follow up to our discussion at TPAC.

At TPAC, we had an unconference session where we talked about how Server Sent
events could be implemented in a connectionless way using OMA Push and fallback
to a push proxy.

I think that it would be useful for this to be mentioned, as informative
language, in the spec, since this could be an important reason why a developer
might choose to use server sent events, rather than just doing long polling. 

There are three reasons to add such language:
* To inform users that this is a reason that they might want to user server
sent events
* To inform implementors of user agents that this is a feature they might want
to implement
* To inform network operators that this is a feature they might want to
implement


I believe I said in the meeting that I would file a bug report. Here it is :-)


I suggest adding informative language something like the following to the spec
for Server Sent Events:


== Implementation as Connectionless Push ==

[this section is non-normative]

If supported by the network, an EventSource may be implemented using
connectionless push, without requiring the client to maintain a connection.
This can save considerable power, relative to a long polling implementation
using XMLHttpRequest.

For example, if the user agent and network both support connectionless event
proxying, then an event may be handled using a timeline like the following:

* User agent connects to server, and requests events
* User agent decides to save power by going to sleep
* User agent disconnects from the server
* User agent contacts a "push proxy" provided by the network, asking it to take
over management of the event source
* User agent goes to sleep
* Push proxy connects to the server, posing as the user agent
* Server delivers an event to the push proxy
* Push proxy uses a technology such as OMA Push to wake up the user agent
* User agent wakes up, and restores its connection to the server


-Rob


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 23 November 2009 23:31:50 UTC