Meeting minutes
Minutes Review
<kaz> Jan-22
Cristiano: We went through a lot of issues
… and discussed a lot of them
… oh, there is a typo in my name, Kaz
… briefly discussed scheduling, but for now we will keep the weekly schedule
… there is also a typo in Zoltan's name
… other than that, I don't see any obvious issues
Kaz: Names have been fixed, should be updated now
Cristiano: There is one instance of "ZK" for Zoltan remaining
Kaz: Also updated
Cristiano: Alright, any objections to accepting these minutes?
… hearing none, the minutes are accepted
PRs
<kaz> PR 489 - Better types for Scripting API
Cristiano: I put PR 489 here, although it is stalled at the moment
… requires probably one day to deal with thoroughly
… will carry it over as a reminder
Issues
Cristiano: there are a number of new issues opened which I would like to include in today's agenda
… please speak up if you have any other points
… issues have been raised by two new people, maybe new users of the scripting API
… one issue is by Fady
… (adds the new issues to the Agenda in the Wiki)
… (also adds one issue by Jan and one regarding typescript definitions to the Wiki)
Cristiano: Will add your issue to the bottom, as Zoltan is currently not in the call
Jan: He just wrote that he is having technical difficulties, unfortunately
Issue 540
<cris_> Issue 540 - A mistake in subscribeEvent logic
Cristiano: This is a pretty easy issue
… I already labeled it as a bug
… as Fady mentions that we have a mistake in the subscribeEvent algorithm
… he wrote that the check for the presence of an eventName in the activeSubscriptions is currently reversed, for me it makes sense to fix this
… he also warned us that a similar issue exists in the observeProperty algorithm
… maybe we can decide in this call on fixing this
… I am also seeing a WebIDL syntax error here
… more impotantly, the logic in the case of observeProperty is the other way around and we should decide one the way to handle this
Jan: Seems like there is an equals sign missing in the square brackets
Cristiano: The other terms are correct, apparently
<kaz> 8.11 The subscribeEvent() method
Cristiano: (adds a comment to the issue)
… does anyone want to volunteer to fix this
… (assigns himself)
Kaz: In that case, we not only need to fix subscribeEvent but also observeProperty, right?
Cristiano: Exactly, but with different fixes
<kaz> 8.9 The observeProperty() method
Cristiano: subscribeEvent needs a logic fix, observeProperty needs a syntax fix
Issue 539
<cris_> Issue 539 - ObserveProperty with uri vars
Jan: I've categorized the issue, the point is that if you are using URI Variables the key should be same or not?
... not sure what is about
... Seems to be also related to issue 540
Cristiano: Yeah, other than that it is referring to URI variables. If you want to subscribe to an event, you can subscribe to a different kind of event via URI variables, but only one subscription can be stored
… we can not subscribe again with different URI variables
Jan: Yeah, you would need to cancel the first subscription first
Cristiano: Is this a use case? And how can we solve this?
… (starts adding a comment to the issue)
… I would say, you cannot subscribe concurrently and have two active subscriptions to the same event
… one workaround would be to consume the TD twice
… but this might create other issues with open connections
… so you have two options, the other being unsubscibing and then subscribing again
… this could even be a use case with a short user story
… "as a user, I want to subscribe to the same event twice with different URI variables"
… should we label this as a use case?
Jan: I would say it has a use case, but it does not have the highest priority. You could also simply create another event in the TD
Cristiano: Will label it as low priority, also considering that URI variables might change in TD 2.0, probably also relates to the DataSchemaMapping topic
Zoltan: Consuming the TD multiple times is not an ideal solution, as we are having URI variables for a purpose like that
… what does the TD spec say about that? What if you make a subscription with or without URI variables?
Cristiano: I think the TD spec does not say much about it
Zoltan: Then it seems underspecified
… we should probably support multiple subscriptions, should file a bug for our own specification
Cristiano: Check for active subscriptions should include the URI variables
… can also test it out in node-wot and then provide a more thorough fix to the specification
… (finished the comment in the issue)
Daniel: You could also add the "Bug" label to the issue
Jan: Should we also add a "use case" label?
Cristiano: Yeah (adds the two labels)
Issue 537
<cris_> Issue 537 - Proposal: use TD default values
Cristiano: I think here the user is trying to create a feature request for the Scripting API
… it is about supporting "default" values
… the question is whether we can that into account, for example for ExposedThing
Daniel: They also mention that you would not need to create a handler in the case a default value is present
Zoltan: I don't think this is really serious, it is a possible use case, but I would like to see more developer feedback on this, adding a simple handler that returns 5, for example, is not that much work
Cristiano: Could be more relevant for the Consumer side
… if you know that a payload will always return 5, you could invoke an action without passing a payload
Daniel: Also, you would always need a JSON Schema library and there might be implementations that don't want to add this dependency
Cristiano: For example, ajv does this automatically
… at least Ege told me that there is a feature to add default values automatically
… but this should not be required
… (adds a summary comment to the issue)
Issue 536
<kaz> Publish thing-description TypeScript package
Cristiano: This issue has popped up
… maybe there were some changes in the TD JSON Schema?
Daniel: Usually I resolve this kind of issue asynchronously
… in this case, it seems to be only whitespace changes due to the formatting changes in the TD repo
… so we could simply skip it
Cristiano: I also think we should skip it
Daniel: The version number also has not changed, so publishing a new one would work directly
Cristiano: Is everyone okay with just closing it?
Jan: Sounds resonable
Cristiano: I will ping Ege for feedback, then next time we could close it
Issue 535
<cris_> Issue 535 - Dedicated methods for DNS-SD, CoRE Link-Format discovery, and other approaches?
Cristiano: Zoltan has already left, unfortunately, so we should postpone it
… maybe you can also answer to Zoltan's comments in the meantime, Jan?
Jan: Will do
Issue 392
<cris_> Issue 392 - Use-case due diligence
Cristiano: I was wondering if we can close this one as an outdated issue as we are reworking our handling of issues in the Working Group more generally
Daniel: I second that, I also commented twice there that the discussion got stalled
… is anyone else using the CSV file anyway?
Cristiano: I agree, the file is kind of outdated anyway due to the new use case work
Kaz: Given the current situation, meaning that the issue was created two years ago, we can close it, I agree
… However, we should collaborate with the Use Case TF in the current period on this topic more closely
Cristiano: (adds a summary comment to the issue and closes it)
Issue 206
<cris_> Issue 206 - Clarify Discovery API scope
Cristiano: We discussed this last time but I am not sure why we did not close it
Daniel: I think because of Jan's comment, right?
Cristiano: Let's double-check with the minutes from last time
… (checks the minutes)
… ah, it was a homework for Zoltan
… we can ping him
… (adds a comment to the issue, pinging Zoltan, and adds the label "Waiting for feedback")
Label "wait for TD"
Cristiano: I reviewed most of the issues we currently have
… so here is the list of issues I wanted to discuss with the TD Taskforce
… (shows the list)
… are you fine with this list or do have any proposals for how we should proceed with this activity?
Daniel: I think like you said, we should bring these issues to the use case taskforce and see how it fits in with their work
Cristiano: I am also wondering whether we should first talk to the TD TF
… maybe what is also missing is how high the priority for these issues is for us, also in relation to the priority the TD TF has for them
… maybe we can just filter out the issues with a high priority for us
… (adjusts the filter in the issue overview)
… should we ask for a slot in the TD call with this list?
Daniel: Maybe we can create an issue in their repository and link this list
Cristiano: Most of these are also not new use cases but rather questions of how to deal with them in practice
Daniel: More like clarifications
Cristiano: Or fixes
… maybe in the next call, we can go through the issues together and then link corresponding issues
Daniel: Just a comment regarding the use case call: Who is joining the call?
Cristiano: I am joining
… I am trying to join most of them
Kaz: Technically, Mizushima-San is the leader of the Use Case TF, so we can talk to him regarding use case questions as well
Jan: I am also joining the Use Case call
AOB
Cristiano: Any other topics?
… hearing none, then we can adjourn
[adjourned]