- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Tue, 06 Sep 2011 23:44:54 +0200
- To: Robin Berjon <robin@berjon.com>
- Cc: www-dom@w3.org, public-device-apis@w3.org
* Robin Berjon wrote: >In both cases we have a situation in which registering an event using >addEventListener() is said to immediately (but asynchronously) trigger >an event for the given event type. The first test you should put into the test suite then is what happens if the listener registers itself when triggered, and contact developers of debugging tools that they can't add listeners for these events since that would change how the code they are supposed to help debugging be- haves. Similarily, in the FAQ, the first question to answer would go a- long the lines of "I did this seemingly unrelated thing but now battery status code behaves strangley, why?" And by the looks of it the next, "How do I get the status directly without waiting for an event, to warn users their battery will run out half way through the live stream they are about to pay for?". You want to bind code to an object for synchronization purposes, keep the battery meter in sync with the actual battery status, or tell your favourite advertisement corporation where you plug in your device, or whatever. Doing that by monitoring state transitions is rather fragile, it's quite common for instance that applications break because you've switched out of a state through unexpected transitions, like dragging and then releasing the mouse button outside the area where mouse events were expected, so the applications thinks you drag while you don't. If instead you had told the system you want to synchronize with the cursor in a certain area, odds are much better that this does not happen. Anyway, there isn't really much to comment on here as you do not offer the rationale for using the event system to begin with instead of some alternative; you could make a getBatteryStatus(callback) function that returns true or whatever if it wants to be called with updates for in- stance, which is a common idiom, or have a system like .batteryStatus.bind("sync", callback); // called "now" and "later" .batteryStatus.bind("crit", callback); // called when "critical" ... or whatever, but you ended up using events, and without understanding why, what discussion you already had about this, we can't develop an idea of what might be best for your specification without rather use- less back and forth. What you are proposing is clearly an abuse of the event system that is likely to cause minor problems, but if that is the best people can come up with, staring a little deeper down into the abyss won't change much at this point, the princess is in another castle, anyway. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Tuesday, 6 September 2011 21:45:15 UTC