- From: <bugzilla@jessica.w3.org>
- Date: Fri, 21 Jan 2011 23:35:21 +0000
- To: public-webapps@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11836
Summary: Don't specify the transport, just specify API and
protocol
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Server-Sent Events (editor: Ian Hickson)
AssignedTo: ian@hixie.ch
ReportedBy: robert@broofa.com
QAContact: member-webapi-cvs@w3.org
CC: mike@w3.org, public-webapps@w3.org
EventSource shouldn't concern itself with transport issues that aren't directly
related to what's required to drive the EventSource API.
Conceptually an EventSource is simply a client-side API that is driven by an
EventSource data stream. Whether that stream is an XHR request, or a
WebSocket, or a raw TCP stream is not important to the core purpose of an
EventSource. Trying to specify the details and interface required to implement
a specific transport (e.g. what domain restrictions should be imposed) will be
confusing when there are already multiple specifications in place for exactly
this (i.e. XHR and WebSockets).
Instead, the EventSource interface should abstract all this out by adding a
"transport" property that points to "the implementation-specific object used to
connect to the server". This will allow developers to access the internals of
the transport as needed, without having to mirror the API in the EventSource
interface. (For example, the Mozilla XHR object has a "withCredentials"
property that developers will want to access when doing cross-domain requests.)
You might also want to clarify that the "readyState" property and the
open/message/error events are not expected to correspond directly to any
similar interface in the transport object, even though similarities are
expected.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 21 January 2011 23:35:23 UTC