See also: IRC log
<kaz> scribe: Yingying
<kaz> scribenick: yingying_
<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.
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]