- From: Futomi Hatano <futomi.hatano@newphoria.co.jp>
- Date: Fri, 09 Oct 2015 00:07:22 +0900
- To: Sangwhan Moon <sangwhan@iki.fi>, public-websignage@w3.org
On Thu, 8 Oct 2015 21:40:46 +0900 Sangwhan Moon <sangwhan@iki.fi> wrote: > > 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. Agreed. > >> 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.) Absolutely. Putting aside the question of Power-on API, I don't want to open up the can of worms for abuse. We should not focus on general web browsers or open app-platforms such as smartphones. We should focus on some kind of dedicated devices such as signage terminals, home servers, etc. The browser runtime on such dedicated device is not used for browsing arbitrary web sites. For example, the browser runtime in a web-based signage terminal just accepts a pre-defined URL. The contents running on the browser runtime are completely controlled by the service operator. I think that such cases doesn't introduce can of worms, such as security or privacy issues. On Thu, 08 Oct 2015 10:00:37 +0800 Kai Hendry <hendry@webconverger.com> wrote: > > 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. As Sangwhan mentioned, Mozilla Web APIs are helpful. https://wiki.mozilla.org/WebAPI Chrome apps APIs is also helpful. https://developer.chrome.com/apps/api_index Power management, Bluetooth (discovery and SSP), BLE, USB, Serial (via USB), Alarm (kind of cron) etc. Others, GPIO, I2C maight be also nice for SBCs such as Raspberry Pi, CHIRIMEN etc. * Raspberry Pi https://www.raspberrypi.org/ * CHIRIMEN http://mozopenhard.mozillafactory.org/ Cheers, Futomi -- Newphoria Corporation Chief Technology Officer Futomi Hatano -- futomi.hatano@newphoria.co.jp http://www.newphoria.co.jp/
Received on Thursday, 8 October 2015 15:07:55 UTC