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
