Re: Proposal of new requirements for the Web-based signage toward W3C standard

> On Oct 8, 2015, at 11:00 AM, Kai Hendry <hendry@webconverger.com> wrote:
> 
> Hi there,
> 
> Since I won't be attending this F2F meeting, I hope you don't mind me
> sharing how Webconverger does this over email.
> 
> On Wed, 7 Oct 2015, at 08:35 PM, Shigeru FUJIMURA wrote:
>> For example, if more low-level operations on terminals, such as changing
>> mode from sleep to normal or restarting to recover from troubles,
>> through browser are capable, I believe it increases the potential of
>> Web-based signage.
> 
> The way we have implemented this in Webconverger is with a secure Web
> socket connection from the client to our configuration server.

This approach more or less is what I would do if I had to implement the same,
although standardizing this particular approach is another question - W3C might
not be the best place for it.

>> From the configuration server you can trigger browser restarts, change
> screen blanking (sleep) and such: https://webconverger.org/API/
> 
> Here is the source of the client: https://github.com/Webconverger/wsc <https://github.com/Webconverger/wsc>
The problem with a power control API is not turning it off or rebooting (although
restarting the process could be a bit tricky. Chromium I think would be possible
by doing something creative with zygote, but will need to experiment.) but turning
it on. I don't really think this is something that can be defined as a API, since the
power being off essentially means the runtime is well, off.

(Also, there is the hairy part where this API opens up the can of worms for abuse,
which probably means a permission model should come in.)

There is also a API that is used in Gaia, which isn't standardized but a starting point:
https://developer.mozilla.org/en-US/docs/Web/API/MozPowerManager <https://developer.mozilla.org/en-US/docs/Web/API/MozPowerManager>

They are also missing the powerOn() API, for the obvious reasons mentioned above.

> 
> 
>> We would like to start the discussion with a view to launching working
>> group and making standards. Would you please join this discussion?
> 
> I'm not sure what that standard would look like, but in our case you can
> trigger changes to many many Web signage devices by simply curl-ing an
> update to the configuration which that device is mapped to. It's fast
> and scalable as long as the Web socket is stable.
> 
> 
> Kind regards from Malaysia,
>