W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2006

[whatwg] Some comments on server-sent events

From: Anne van Kesteren <fora@annevankesteren.nl>
Date: Wed, 23 Aug 2006 18:58:17 +0200
Message-ID: <op.teqxffe6aw9dld@id-c0020.oslo.opera.com>
* The event-source element has no DOM interface while it has some
attributes that probably warrant one.

* The specification doesn't define when the onevent event handler is
invoked nor when the event event is dispatched. They are only defined.
It's also unclear which interface they implement, et cetera.

* A problem with the event-source element is that the resource is loaded
before you can attach event listeners to the document. Perhaps the loading
should start after the load event is dispatched? Unless the element was
inserted into the document of course (that's actually also a bit unclear).

* Since event sources can be attached using other ways than using the
event-source element the Target field should be amended to take that into
account. (Some sentences there don't make sense for an event source
attached to an object that is not an event-source element.)

* Regarding that, I'd be interested in hearing the use case for allowing
any EventTarget to be a source for server-sent events.

* Event namespaces throughout should be changed to match DOM Level 3
Events. That basically means that http://www.w3.org/2001/xml-events is
gone.

* Perhaps RemoteEvent should be replaced with a reference to CustomEvent
  from DOM Level 3 Events which offers the same type of functionality?

* What happens when the event given in the Event field doesn't match the
NCName production as required by DOM Level 3 Events such as in the example
in section 7.1.7? (It uses the event "stock change".)

* At the moment the BNF does need error handling because you could have a
";" at the start of a line without any data following (or a new line for
that matter).

* It might be better to replace the BNF with something similar as the HTML
parsing specification currently has. That provides a much more clear
processing model.

* What happens for other line feed characters? Are they treated as fields?
Won't that give lots of problems for authors coding in non-Unix formats?
HTTP for example allows both.

* "For each non-blank, non-comment line, the field name is first
taken[...]" doesn't cover what happens to command lines.

* "The ctrlKey field would be ignored[...]" should probably say
"keyIdentifier" as that's what's used in the example.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Wednesday, 23 August 2006 09:58:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:28 UTC