Re: Server-Side Events encoded in JSON

2011-04-29 Thread Benjamin Goering
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


Server-Side Events encoded in JSON

2011-04-28 Thread Brett Zamir
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