W3C

Scripting API TF Meeting

14 Nov 2016

See also: IRC log

Attendees

Present
Dave_Raggett, Kaz_Ashimura, Johannes_Hund, Uday_Davluru, Yingying_Chen, Zoltan_Kis, Masato_Ohura
Regrets
Chair
Johannes_Hund
Scribe
Yingying

Contents


<kaz> scribe: Yingying

<kaz> scribenick: yingying_

discussion with Mozilla about the scripting API

<inserted> discussio with Benjamin

Johannes: the basic question is whether we should standardize the scripting API.
... my basic question is whether we should reconsider the standardization of scripting api and the scope.
... we are also looking for the solution to expose thing and consume thing. this is one argument however we were not so successful with this argument.
... what is the delta between the RESTful API and our scripting API.
... there are quite a lot of mail exchanges already.
... maybe we need to think one again why we need to standardize scripting api and what is the delta from REST APIs.

Zoltan: the argument from Mozilla makes sense for client API. But for the server side we need the scripting API standardization.

[Johannes is creating a new issue in github]

<inserted> Issue-272 on Rationale for Scripting API

Johannes: we have the portability requirement. If no scripting API we could not reuse the logics between things. In my view, only if we have some standardized APIs we can rely on that we could have the portability.
... any other arguments for our scripting API standardization.

<Zakim> dsr, you wanted to discuss pros and cons for low level API

Dave: The level of APIs between app and resource. Negative part is introducing so many libraries for web developers.

Johannes: complementing the work of TD and Protocol bindings and resource model.

discussion with Mozilla about the scripting API

Johannes: we now have two proposals for the scripting API. We need to think how to merge these and put into current practice document.

-> https://github.com/thingweb/wot-typescript-definitons/blob/master/src/index.d.ts

[Johannes is explaining the code.]

Johannes: what do you think of dividing the objects in this way?

Zoltan: I like it. We should input these kinds into github. It would be helpful to convert the APIs.
... better be agree on the context of the APIs we need to follow.
... we could synchronize using emails.

Kaz: I agree with you both. Scripting API is specifically for TD. It's different from specific programming languages.
... for automotive, we have 2 level of APIs: javascript based API and WebSocket API.
... our scripting APIs are different from those as scripting APIs are for abstraction level APIs.

Johannes: we had lot of discussion on use cases we try to address.
... let's have a short recap for this.

Kaz: as we've been talking during the WG charter discussion, we should discuss again the use cases when the WG is launched.

-> https://github.com/w3c/wot/blob/master/ucr-doc/WoT_CommonView_KickOff.pdf

Johannes: can we reuse the atomic use cases we did at the very beginning?
... what are the basic functionalities for scripting APIs are what we want to address.

<kaz> s/tommy/atomic/

Johannes: how to make the catalogs?
... just select some of those or what else?

Dave: the ucr document can be the starting point but we need to consider people's opinions who join the group.
... we also to consider the commercial use cases to see what already exist and go forward.

Zoltan: we have couple of basic scenarios and we don't need much. I just need to collect some and we can create issue on them per people's comments.

Kaz: I agree with Johannes, Dave and Zoltan. W3C usually hold use case discussions several times. The first phase UC, then summary of UC and more UC when new participants come in.
... the accessibility guys can also bring in more UCs. We can simply start the UC discussions and add more.
... we can categorize them, e.g. accessibility category, smart home category, etc.
... if there are similar UCs we can merge them into one category.

Johannes: The most important thing is that we need to have the structure we would like to work in.

<zkis> fully agree to work on github

Johannes: I personally prefer to work on github rather than on wiki and later transfer to github.
... it makes sense to have a new folder in github as scripting to create a structure we need at the moment.

Kaz: maybe we could start with the very first version in wiki and transfer it to github once we have some.

Zoltan: I prefer github.

Johannes: we have a wiki. If people are not familiar with github, they can contribute there and we can make a transfer.

Dave: on github it's easy to create the thread but it's not very easy to view.

Johannes: make a conclusion when issue closed to help people from creating pull request on their own.
... consensus is that we work on github. The editor should be flexible.
... I will create the folder and move the proposals folder and my type-script-definition folder into it. and add subfolder for UC.
... second document is to provide the initial template how we merge the comments.
... I will try to do that next week.
... there were discussions before and during TPAC, there will be a community group web assembly.
... it's just in the beginning phase. I will try to get them into next call.
... if there is other topic you want to discuss, please let me know.

[adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/11/14 13:08:29 $