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
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").
- Server-Side Events encoded in JSON Brett Zamir