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> PR 318 - Introduce thing description type from json schema
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> PR 319 - Add a github action to automatically sync the json schema
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> https://
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> wot-profile PR 77 - New Protocol Binding section
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