[eventsource] Event names

> 3. Otherwise, create an event that uses the MessageEvent interface, with
the event name message [...]
> 4. If the event name buffer has a value other than the empty string,
change the type of the newly created event to equal the value of the event
name buffer.

I'd suggest consistently saying the "event type", rather than using both
"event name" and "event type".  It sounds like it's referring to two
different things, so I had to read this a few times to figure out what it
meant.


This allows sending messages with names equal to those of the API's own
events.  Should it prohibit using "open" and "error" as event names, so
remote messages can't fire events that look like connection-state events?
These are very obvious choices for people to use as event names, so I could
see this leading to obscure bugs.

Alternatively, give remote event names a prefix; for example, if an event is
sent with the event name "update", fire the event "server:update".  That has
the advantage that, if additional events are added to MessageEvent in a
later spec, they won't conflict with server event names that people are
using--the namespaces are clearly separated.

-- 
Glenn Maynard