- 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