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 <> 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 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.

Reply via email to