previousResult not really stored anywhere

[marcoscaceres]

The |previousResult| var is mentioned up in various algorithms, but is not stored anywhere persistently... it also feels like an optimization (if you have a cached one, return it). Could we either:

1. put it somewhere as an internal slot.
2. drop it.

My preference would be to drop previousResult. Caching a string (enum) value doesn't seems particularly useful.

[jyasskin]

It's more semantic than just an optimization: it prevents the UA from returning completely arbitrary values on back-to-back calls. It's not exactly the same as the required caches to ensure foo.bar===foo.bar, but seems related.

Storing the value somewhere explicit makes sense: we'd clear that storage when the UA receives new information about the user’s intent.

[marcoscaceres]

It's more semantic than just an optimization: it prevents the UA from returning completely arbitrary values on back-to-back calls.

Understood. But I think we need to hook that into the eventing model. There should only be a single view of what the permissions are before we get "new information about the user’s intent" (or the permission states get updated because the world changed).

Storing the value somewhere explicit makes sense: we'd clear that storage when the UA receives new information about the user’s intent.

Agree, yes.

It be nice to more clearly articulate in the spec (maybe in terms of a map) how realms and permissions map to each other. It's not sure clear (from my reading) how that works.

[miketaylr]

In the year 2022, previousResult isn't even defined. But it does show up 4 times, in 2 places, and has a typo in both:

If there was a previous invocation of this algorithm with the same name and settings, returning[sic] previousResult, and the user agent has not received new information about the user's intent since that invocation, return previousResult.

https://w3c.github.io/permissions/#dfn-extra-permission-data-type https://w3c.github.io/permissions/#dfn-getting-the-current-permission-state

So at the very least we should define it (again?).

[jyasskin]

The meaning there might be clearer if it said "If there was a previous invocation of this algorithm with the same name and settings, that returned previousResult ...”? That's the defining instance of the variable, anyway.

[miketaylr]

I see, that's totally not how my brain interpreted "returning |previousResult|".

[miketaylr]

(thanks for the suggested clarification @jyasskin)

[miketaylr]

I guess this could be solved by #384.