Server-Sent Event types

I am a newcomer to the Server-Sent Events spec, so my apologies if I am 
covering old ground.

While I can understand that Server-Sent Events may be intending to start 
off simple, I wonder whether there is some reason a formal mechanism was 
not adopted to at least allow the specification of event types. I think 
such a convention would have a number of important benefits.

Of course, one can already simulate event types:

1) One could exclusively alter the data itself to embed such types, but 
this pushes more responsibility for parsing the response data to the 
user (and will increase the amount of data needing to be transferred, 
both for the need to always respecify for each message the type in the 
data stream, as well as for the need of a particular client to receive 
all types of data even if it didn't register itself for receiving that 
type). And that parsing of types would not end up becoming familiarly 
uniform for users of libraries, and would not be conducive to 
extensibility; if someone wished to add new events later on, old 
client-side code might need to be rewritten.

2) One could instead simulate event types by supplying a different URL 
or a URL with different parameters, but with the disadvantage that 
multiple requests would presumably need to be established for each 
parameter combination--adding unnecessary connections and an inability 
to handle different types within the same response handler. Moreover, 
without a specific REST type of convention for event types, there again 
would be no familiarly uniform way to specify event types, preventing a 
clear and easy way to add new event types.

It would seem to me that the specification could still be kept simple, 
while still offering safer and more convenient flexibility for the 
future, if something like the following were followed:

1) The EventSource object could be optionally supplied with a particular 
query string parameter (e.g., sse-type= or sse-types=) (if not also as a 
key-value object second argument). If no other types were added, the 
data stream itself would not need to encode type, although a type 
property could still be set on the event object (see below). This would 
allow a common convention, regularizing client-side and server-side 
library creation, and in the case where only a single type were 
specified, avoids the need for extra data to be added to the stream to 
indicate type.

2) For cases where the application did wish to share a connection for 
different types, an analogue to addEventListener could make it possible 
for the client to notify the server to add more types to the stream 
while reusing the same connection (though this would require some 
additional mechanism, such as a different REST parameter like 
"add-sse-type=" if not adding to a two-way stream). A type property 
could then be made available on the response event object to allow the 
user to be able to conveniently filter the types depending on the 
response and the state of the client application, without the need for 
hackish and non-uniform parsing of response data.

3) Custom event types should be indicated by some unique mechanism 
(e.g., requiring unrecognized types to be preceded by "x-") so that if 
the specification were to be expanded upon in the future to support 
official protocols, they could do so without impacting existing code. 
However, when no type is supplied, this could also be assumed to be a 
custom event, but without any "namespace". This would allow the 
specification to be backwards-compatible.

It seems to me that the above suggestions would not add an undue amount 
of complexity (and avoid or postpone any commitment to defining specific 
event types), while also providing a better framework for manageable 
extensibility into the future.

Best wishes,
Brett

Received on Thursday, 28 April 2011 19:30:14 UTC