W3C home > Mailing lists > Public > public-websignage@w3.org > November 2016

Re: Unofficial API draft "Device Information API"

From: Futomi Hatano <futomi.hatano@newphoria.co.jp>
Date: Tue, 01 Nov 2016 19:22:39 +0900
To: "Kiyoshi Tanaka (田中 清)" <tanaka.kiyoshi@lab.ntt.co.jp>
Cc: public-websignage@w3.org
Message-Id: <20161101192237.0541.17D6BAFB@newphoria.co.jp>

On Tue, 1 Nov 2016 18:57:27 +0900
Kiyoshi Tanaka (田中 清) <tanaka.kiyoshi@lab.ntt.co.jp> wrote:

> 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.

Yes.

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

Yes in most situations, I think.
But it depends on each signage service system.
Some services would require the information when the JS player
starts, some services would not.
We should not limit the timing when the API is called.

> 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? 

Generally, XHR or WebSocket would be used.

> Moreover, if such a information is used to limit
> the number of connections to the licensed number, how do it reflect
> the terminal management?

Most of signage systems return an error code to the terminal.
That is, such terminal won't work as a signage terminal.

Basically, such terminals are NOT managed by the CMS.
It's not limited to signage systems.
It's common in licensed software or web services.

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

Please feel free to ask me any questions.

Cheers,
Futomi

> 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/>
> >
> 
> 
> 

--
Futomi Hatano,
Newphoria Corporation
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/
Received on Tuesday, 1 November 2016 10:23:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:23:31 UTC