Re: Wake Lock API as [Observable] candidate, Re: [whatwg] Object.observe()able properties on the web platform

On August 25, 2014 at 5:27:20 PM, Jonas Sicking (jonas@sicking.cc) wrote:
> On Mon, Aug 25, 2014 at 11:55 AM, Marcos Caceres wrote:
> >
> > ```
> > document.keepScreenOn = true;
> > ```
> >
> > Versus, say:
> >
> > ```
> > window.WakeLock.keepScreenOn = true;
> > ```
> >
> > Your guidance would be much appreciated.
>  
> The first problem, like you mention is that the API needs to be
> asynchronous. This to enable things like policies that involve user
> UI, or policies that require slow processing like IPC.
>  
> So something like:
>  
> document.requestScreenOn();
> Object.observe(document, myHandler, ["screenLockedOn"]);
>  
> would be better. Where document.screenLockedOn is a readonly property
> which changes to 'true' any time the lock is actually granted, rather
> than just requested.

Agree. Good point in general. We were hoping no UI would be needed for this particular API (but I guess you never know, and it's a good pattern to use).     

> The second problem with the above is that it makes it very hard for
> components on a webpage to cooperate about keeping the screen on.
>  
> If this is a use case that we at all care about then I think we need
> something better. For example something like:
>  
> x = new ScreenWakeLock();
> x.request();
> object.observe(x, myHandler, ["lockGranted"]);
>  
> would make it much easier for separate components on a page to not
> stomp on each other's locks.


Sorry, I (and the other Editor) are still having a hard time understanding why this is easier. 

If you have 2 (or more) locks:

```
x = new ScreenWakeLock();
x.request();
object.observe(x, myHandler, ["lockGranted"]);

//some other script later creates "y"
y = new ScreenWakeLock();
//auto granted... page is allowed to request. 
y.request();
object.observe(y, myOtherHandler, ["lockGranted"]);
```

Does changing x.lockGranted also change y.lockGranted? If so, then you have some weird interdependencies created and x can still stomp on y, no? If y still holds the lock, then you can never be assured that the lock has actually been released (so you get stomped on if someone loses a lock - which could potentially be hard to track down).   

In any case, it seems to me that what you are proposing gets super messy (for developers) because you need to track multiple locks. Having a single "source of truth" (a static) seems much more sensible and easier to manage to me personally. Then you only have one point of reference and you can observe it changing from a single place - and if a dev needs better lock management, they can build a locking manager on-top of that.  

Sorry, I know we've gone through this on the WHATWG list - but I'm not the only one confused by the logic of having a constructor here :(

Received on Monday, 25 August 2014 22:26:30 UTC