Re: Unofficial API draft "Device Information API"

Thanks for your comment, Sangwhan.
I reply inline.

On Wed, 19 Oct 2016 10:50:55 +0900
Sangwhan Moon <sangwhan@iki.fi> wrote:

> Sangwhan Moon
> > On 19 Oct 2016, at 3:20 AM, Futomi Hatano <futomi.hatano@newphoria.co.jp> wrote:
> > 
> > Hi all,
> > 
> > At the Group meeting at TPAC 2016, we listed APIs
> > which will be disicussed in the incoming WG.
> > https://www.w3.org/community/websignage/wiki/Group_meeting_at_TPAC_2016#APIs
> > 
> > Though the WG has not been chartered yet, I tried to
> > create an API draft "Device Information API".
> > You can see the draft on my personal github account.
> > http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html
> > 
> > I know that the "Device Information API" is not decided to
> > be included in the scope of the WG.
> > I just hope this draft makes our discussion active.
> > 
> 
> Just as a curious question, why Promises? Most of that information is static, so everything is already known at the time of creation and returning said DeviceInfo object should be instant, if not in constant (and very short) time.

Yes, you are right.
The synchronous API is ideal because the information is
always static as you mentioned.

As you can see in the section "6. Design principle of the API",
The reason the API is asynchronous is just compatibility with
the mechanisms implemented in existing web-based signage
terminal devices.

I just thought that manufacturers can take advantage of
the existing mechanism they have implemented in their
products and they can implement this API easily.

Nevertheless I'm not sure that Promise is the best for this API.
If Promise is not helpful for manufacturers (implementators), 
this API should be synchronous, I think.

> The only case where the promise makes sense is if the context has navigated away from the initial URL (if I understood the design correctly) but if it's a synchronous API, this would be a security violation so throwing would be perfectly appropriate. 
> (Additionally, this simplifies the implementation for implementors who will be implementing this with say, addJavascriptInterface())

I could not understand the phrase above.
(Just because my English understanding is poor)

Why a synchronous API whould be a security violation
if the context has navigated away from the initial URL?
I wonder an asynchronous (Promise) API would be a security
violation as well.

Anyway, this API can be called only from origin of the
initial URL.
http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html#protecting-security-and-privacy

> (I'm a non-member, so take my input as a simple comment)

Your feedback is helpful.
I always welcome you.

Cheers,
Futomi


--
Futomi Hatano,
Newphoria Corporation
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/

Received on Wednesday, 19 October 2016 02:40:40 UTC