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

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

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Fri, 26 May 2017 15:48:47 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-304317859-1495813725-sysbot+gh@w3.org>
>>  As an internal slot, it can still have side effects on the JS side.

> Then it would be bug for the browser that introduces such side effects, internal implementation should not affect specified behavior.

I meant that changing it in the middle of an event turn could be observable in JS. Sorry for the confusion.

>>  But this is implementation specific, it is not specified by the spec, is it?

> Well, we had consensus that it should be true for event loop turn. If that is not in the spec, maybe we should reflect that agreement, do you want me to make PR for that? 😄

I'm not sure what you mean. I don't recall discussing this before. Nor should it be a topic of consensus. Having an attribute change value in the middle of an event turn isn't something you want to see on the platform at all. This is not subject to discussion.

Would you be confusing this issue with `slowSensor.x === fastSensor.x` which has been the subject of a number of discussions?

If not, before submitting a PR, could you please enlighten me on how you would solve this besides the step-switching I suggested above?

> > I don't think it is, tbh.

> I think tbh :) and we have tests for that that actually work.

Well again, I'm not arguing your implementation doesn't do the right thing. I'm saying I don't think the spec guards against this issue, but as I said, this is an area where I don't have a great understanding of how the spec works. The people I talked about this on the #whatwg seemed to imply that we should be calling the whole thing from a task to avoid the `latest reading` changing mid-script.

>> I think we could replace this whole "reporting flag thing" by simply adding the whole "Update latest reading" in a new task.

> Do you want to keep task source event processing model?

We don't have that now. So I'm not sure what you mean.

> New task for what task queue, from what task source?
> Do you know how this is implemented in browsers?
> Do you know why IDB or WebSockets use task queues?
> Do you know how to fix sync side-effects when we have single sensor.reading and multiple tasks in queue?

Nope. But you seem to know a lot about this stuff, so maybe you can help address my concerns, no?

> As I mentioned in this issue, event queues are overkill for such simple event processing model.

Yeah, the people I talked to didn't seem to think event queues would be useful here either. They just suggested having a new task for the Update latest reading algorithm. At least that what I understood.


-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at https://github.com/w3c/sensors/issues/215#issuecomment-304317859 using your GitHub account
Received on Friday, 26 May 2017 15:48:53 UTC

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