W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Server-Side Events encoded in JSON

From: Benjamin Goering <ben@livefyre.com>
Date: Thu, 28 Apr 2011 14:25:48 -0700
Message-ID: <BANLkTi=eXQB0mcS2CWJhTpt92g5K1nEcRw@mail.gmail.com>
To: Brett Zamir <brettz9@gmail.com>
Cc: public-webapps@w3.org
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 <brettz9@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
Received on Friday, 29 April 2011 08:52:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT