[Scripting] minutes - 10 May 2021

available at:
  https://www.w3.org/2021/05/10-wot-script-minutes.html

also as text below.

Thanks a lot for taking the minutes, Cristiano!

Kazuyuki

---
   [1]W3C

      [1] https://www.w3.org/

                           WoT Scripting API

10 May 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#10_May_2021
      [3] https://www.w3.org/2021/05/10-wot-script-irc

Attendees

   Present
          Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura,
          Tomoaki_Mizushima, Zoltan_Kis

   Regrets
          -

   Chair
          Daniel

   Scribe
          cris

Contents

    1. [4]minutes
    2. [5]PRs
         1. [6]PR 318
         2. [7]PR 319
    3. [8]issues
         1. [9]issue 193

Meeting minutes

  minutes

   Daniel: approved previous minutes
   … then discussed with the security task force about open issue
   on runtime provisioning
   … we defined at least two security levels
   … or security realms
   … zoltan is proposing to create a new document for describing
   the high privilege security level
   … then we schedule the call with discovery task force

   Daniel: minutes approved
   … no quick updates

  PRs

   Daniel: we have two PRs related to typescript types from
   ThingDescriptions
   … they look good, but I have two comments
   … first about do we want to keep the package.json

    PR 318

   <kaz> [10]PR 318 - Introduce thing description type from json
   schema

     [10] https://github.com/w3c/wot-scripting-api/pull/318

   Cristiano: I uploaded it cause it may help us to keep track of
   the version of the tool that I am using

   Daniel: ok it's fine we may remove it if we find it
   troublesome.

    PR 319

   <kaz> [11]PR 319 - Add a github action to automatically sync
   the json schema

     [11] https://github.com/w3c/wot-scripting-api/pull/319

   Daniel: another comment is about copying the json schema
   … it might be better to only have one file in the TD repository

   Daniel: don't have a strong opinion

   Zoltan: we could start from here

   Daniel: Also line 78 might not work in node wot

   Cristiano: we could merge it so that I can check it's proper
   behaviour

   Daniel: ok to merge it?

   Zoltan: ok by me

   Daniel: merged

   Cristiano: ok it worked

   Daniel: just maybe thinking again if we can get rid of the
   duplicated schema file

  issues

   Daniel: any comments on the issues from the joint calls?
   … ok seems we still have some work todo

    issue 193

   <dape> [12]https://github.com/w3c/wot-scripting-api/issues/193

     [12] https://github.com/w3c/wot-scripting-api/issues/193

   Daniel: should writeProperty return a value? the use case was
   to give feedback about the written values
   … like returning 1.23 if the application wrote 1.2345
   … http would not return any value
   … lately ben proposed in the profile document that the PUT
   method may return a value
   … even if in the end he said that it is a bad practise to
   return a value
   … in our case we just cannot model the possiblity to return a
   value

   Zoltan: we already have a function for reading

   Daniel: the reason is for automatic reading/writing

   Zoltan: if it is an async system you should deal it with
   synchronization primitives

   Daniel: may proposal is to follow better the possibility from
   protocols

   Zoltan: do we have use case?

   Daniel: yes the one presented before, at least what I had in
   mind

   Cristiano: we should abstract from the protocol binding level

   Zoltan: we have observed property to keep track of changing
   values

   Daniel: I agree
   … but I have another use case
   … it is from the philips hue smart lightbulb

   Zoltan: it is a binding level information

   Daniel: not sure if this is relevant for the application

   Zoltan: is this a writing multiple properties at once?

   Daniel: not sure

   <kaz> [13]wot-profile PR 77 - New Protocol Binding section

     [13] https://github.com/w3c/wot-profile/pull/77

   Zoltan: we might need an operation that writes multiple prop
   and tells that one fails

   Cristiano: yeah true

   Cristiano: I still think this is an issue for interaction model
   of the TD
   … it is a bit profound
   … it touches the definition on the interaction between TDs and
   consumers

   Daniel: going back to the problem should we return a value

   Zoltan: we should wait until it is solved in the design
   … still it is a bit odd returning the written value

   Daniel: I feel like the previous example is good use case
   … but of course returning a whole file is nonsense

   Cristiano: uriVariables is also quite odd

   Zoltan: I agree it is a little bit from a protocol level

   Daniel: I see so do you want to just remove uriVariables?

   Cristiano: well kind of but if we find out that is a common use
   case we could introduce them as optional arguments for
   readproperty

   zotlan: +1

   Zoltan: as an long-running goal we could change completely the
   interaction model, not a request and response
   … we could create a message base api
   … but it's ok
   … we can experiment with it later
   … the problem is that fetch api is really similar

   Daniel: at least our definitions would work with other
   protocols

   Daniel: ok commenting on the issue to summarize the discussion
   so far?

   Daniel: good

   Daniel: adjourned


    Minutes manually created (not a transcript), formatted by
    [14]scribe.perl version 131 (Sat Apr 24 15:23:43 2021 UTC).

     [14] https://w3c.github.io/scribe2/scribedoc.html

Received on Monday, 24 May 2021 09:15:09 UTC