Re: Unofficial API draft "Device Information API"

Dear Hatano-san,

Thank you for sharing your idea of Device Information API as a draft.
I want to clarify how to use your API.

I understand that Device Information API is called from a JavaScript player
which controls displaying contents or some other signage functions.

The information got from this API is static, so is the API used enough once
when a JavaScript player starts to work?

And, I want to know how to use the information exactly.
As I think the retrieved information will be sent to the server (CMS),
how is it done? Moreover, if such a information is used to limit
the number of connections to the licensed number, how do it reflect
the terminal management?

I believe your explanation will help us to understand how the web-based signage
works with this API.

Best regards,
Kiyoshi
---
Kiyoshi Tanaka, Ph.D.
   NTT Service Evolution Laboratories
   mailto:tanaka.kiyoshi@lab.ntt.co.jp


On 2016/10/19 13:26, Sangwhan Moon wrote:
>
>> On Oct 19, 2016, at 11:40 AM, Futomi Hatano <futomi.hatano@newphoria.co.jp> wrote:
>>
>> Thanks for your comment, Sangwhan.
>> I reply inline.
>>
>> On Wed, 19 Oct 2016 10:50:55 +0900
>> Sangwhan Moon <sangwhan@iki.fi <mailto: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 <http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html#protecting-security-and-privacy>
>
> Re-reading my comments, it seems a bit unclear, so to elaborate - a Promise can make sense
> in this context because in a context where device information shouldn't be available (e.g. no
> longer at the initial page) implementations can reject it - and that'll fall into .catch() instead of then().
>
> But at the same time implementations can just throw a exception, which works equally well.
>
>>
>>> (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 <mailto:futomi.hatano@newphoria.co.jp>
>> http://www.newphoria.co.jp/ <http://www.newphoria.co.jp/>
>

Received on Tuesday, 1 November 2016 09:58:18 UTC