All of this functionality can be built upon the current spec, but constraining the spec to support this convenience precludes other uses.
On Wed, Apr 27, 2011 at 11:42 PM, Brett Zamir <bret...@gmail.com> wrote: > user to parse the response text, why not simply allow each event to be a > JSON-encoded object of some kind (boolean, number, string, array, object). > Then the event.data could be an object which was already conveniently > accessible to JavaScript consumers. Presumably server-side libraries would > handle the work of doing the encoding, but the average client-side consumer > should, in my opinion, not need to be concerned with implementation details, > except to become familiar with the specific JSON response types being sent > by the server-side code/library. > > Although this would add encoding responsibilities to the server and > decoding responsibilities to the browser, I think it ought to avoid the need > for the client code to be concerned with ugly implementation details such as > the need to parse strings. > > A convention might also be used in the stream (e.g., "error: " followed by > a JSON object) to trigger errors, allowing the normal responses to be simple > strings or the like, while offering a means to distinguish them from error > messages sent by the server (e.g., to indicate that a data source was no > longer available). The event object could add an "error" property which > could be checked (or, if types were allowed as per my previous post, it > could set the event type to the reserved string "error"). > > Brett > > > > -- Benjamin Goering Hacker, Goofy Guy Livefyre Inc. +1(785)224-0136
