Should SensorReadingEvent carry reading payload?

[timvolodine]

since the sensor reading can be obtained from Sensor directly maybe the SensorReadingEvent doesn't need to carry that information and only signal that reading has changed..

[tobie]

True. What's the reasoning behind that? Simplifying the API?

[timvolodine]

Yes, I think the implementation will be much simpler, especially because we can derive sensors from the general interface. And also if the amount of data is substantial, but that's probably not really an issue for mems sensors..

[tobie]

I'm warming up to this idea, as long as it doesn't hurt developer experience.

[rwaldron]

From experience, devs want to be able to things like this:

sensorA.on("change", event => someGenericDataStoringOperation(event));
sensorB.on("change", event => someGenericDataStoringOperation(event));

TBH, I think that's completely uncool practice, but people like doing things that I don't necessarily like to do.

[tobie]

You should just be able to do this instead, no:

sensorA.onchange = _ => someGenericDataStoringOperation(this.reading);
sensorB.onchange = _ => someGenericDataStoringOperation(this.reading);

[rwaldron]

sensorB.onchange = event => someGenericDataStoringOperation(this.reading);

Wrong this ;)

[tobie]

Yeah, that was precisely in the back of my mind from the very start of this conversation. I need to dig deeper into fat arrow scoping. :-/

So it would be either:

sensorA.onchange = _ => someGenericDataStoringOperation(sensorA.reading);
sensorB.onchange = _ => someGenericDataStoringOperation(sensorB.reading);

or:

sensorA.onchange = function() { someGenericDataStoringOperation(this.reading); };
sensorB.onchange = function() { someGenericDataStoringOperation(this.reading); };

[timvolodine]

yeah so they could just pass sensorA or B to the function no? also if a user only needs a subset of data it makes more sense instead of propagating the whole set every time an event happens.

[zolkis]

This is quite an evergreen topic and pops up with data APIs every now and then. For my taste a vanilla event and data fetcher is better for large data sets, and a specialized event is simpler and better for the generic sensor use case (small amount of data coming at high possible rate):

• with events clients can track better the data changes, without the need to use time stamps.
• subclasses of Sensor will likely have their own data models, which should be encapsulated at their level, and not exposed through a getter at the base.

So what I would do (which is not necessarily what this spec should do, but consider it):

• remove the reading property from Sensor
• provide the data in the SensorReadingEvents of each subclass of Sensor
• remove time stamp (at least for now), that will also tame issue #101
• let subclasses encapsulate their data model
• optionally (but desirable) rename onchange to ondata or ondatachange to denote that it was specifically the data representation of the sensor that has changed, and not some other properties.

[tobie]

Seems there are advocates of both solutions, here. Worth considering the advantages and disadvantages of both and maybe continuing to offer both.

@zolkis, am I right in my understanding of your suggestion that you're advocating for the data to be directly on the event object itself rather than in the reading property?

[zolkis]

@zolkis, am I right in my understanding of your suggestion that you're advocating for the data to be directly on the event object itself rather than in the reading property?

For sensors, yes.

[tobie]

@zolkis, let me be more precise:

Am I right in my understanding of your suggestion that you're advocating for the data to be directly on the event object itself rather than in the reading property of the event? So: event.latitude rather than event.reading.latitude?

[zolkis]

I'd prefer the latter. Since the sensor (type) defines its data interface, I would use a separate property for that, like event.data.latitude or event.reading.latitude.

In most cases a property bag would be enough, but it may even be a fetching interface if needed, depending on the sensor, like event.data.nextChunk().

I've been experimenting with I/O APIs that support configuring the read process with min / max bit length for a reading, and min / max frequency of reading, which influences how data is exposed on the data fetching interface. For this type of use I think Tim's suggestion to expose a reader and use vanilla events would work better, with the reservation that then Sensor should be an interface and not a base class (in Java sense), so instead of subclassing, one could say

interface MySensor { ... };
MySensor implements Sensor;

instead of

interface MySensor: Sensor { ... };

However, with this design, and for this type of sensor use case I would recommend exposing the data on the sensor as a separate object property.

[dontcallmedom]

Decided at TPAC: RESOLUTION: remove event payload from SensorReadingEvent