W3C home > Mailing lists > Public > public-device-apis-log@w3.org > May 2017

[sensors] Use simple event dispatch mechanism instead of task source (queued)

From: Alexander Shalamov via GitHub <sysbot+gh@w3.org>
Date: Fri, 26 May 2017 09:13:46 +0000
To: public-device-apis-log@w3.org
Message-ID: <issues.opened-231569764-1495790024-sysbot+gh@w3.org>
alexshalamov has just created a new issue for https://github.com/w3c/sensors:

== Use simple event dispatch mechanism instead of task source (queued) ==
**Short summary:**

Sensors are operating in simple Publish & Subscribe model, therefore, queued event processing is not required and over-complicates API and it's implementation.

**Detailed explanation:**

Event queue is suitable for cases where ordered task processing is needed. For example, networking, databases or APIs that provide sync API and manage async task queue. You can call `write(data);` multiple times and each write is ordered task, if error happens, all pending tasks are removed from queue and `'onerror'` event task is put to the queue.

**Problems with queued task processing:**
- The `'onchange'` event would need to carry reading data, otherwise when event queue is processed, event would not be in sync with `Sensor.|reading|`
- When we attach |reading| to an event, we will have another problem, `event.reading != Sensor.reading`, might be confusing for developers.

**Pros for simple event:**
- `onchange` is synchronized with `Sensor.reading`
- No need to carry extra data in event.
- No need to manage queue, we don't even need a queue, since we always have 1 update per event loop cycle per Sensor instance.
- Simpler for browser vendors to implement.

**Proposed resolution:**

- Use simple event dispatch mechanism
- Remove task source related information from the spec

Please view or discuss this issue at https://github.com/w3c/sensors/issues/215 using your GitHub account
Received on Friday, 26 May 2017 09:13:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 12:18:53 UTC