Meeting minutes
Minutes Review
<kaz> Aug-5
Cristiano: (Goes through the minutes from last meeting)
… checked them quite some time ago, looked alright
… are there any updates needed?
Daniel: Also looked fine to me
Minutes are approved
Meeting Cancellations
Daniel: I added the holiday schedule as an agenda item
… in two weeks we are in the holidays
… my suggestion would be to skip the 25th of December and then resume on the 8th
Cristiano: The one on the 25th definitely needs to be cancelled
Daniel: Next one will be the 8th then
Kaz: That's fine by me
Jan: For me as well
Cristiano: Will cancel the next meeting via the W3C calendar immediately
… (cancels the next call)
… (the call on the 8th is not appearing in the calendar)
… why can't I see it?
Daniel: Seems like we cancelled everything, the 8th is not showing up anymore
Cristiano: Thought I just updated that event
… ah, but the series of events is only until the first of January
… so that needs to be updated
… (extends the max date range until 2026 in the calendar)
… (calendar event on the 8th appears again, but also the one on the 25th)
Daniel: Looks good now, we just need to cancel the 25th again
Cristiano: (Cancels the event on the 25th again)
PRs
PR 563
<kaz> PR 563 - Explain to get data without validation
Cristiano: We already got three approvals
… solves a long-standing issue with the value() function
… deals with cases where the data schema does not match the returned value
… experienced problems with that during the plugfest, for example
… PR mostly adds explainer text how to deal with this kind of situation
… (shows the rendered diff)
… in fact, we have an assertion in the TD spec that the consumer should expect data from the remote thing
… looks like the rendering of an example is wrong, but that might be an issue with the diff
… the example is a one-liner
Kaz: Quite minor, but the title of the PR has two "to"s
Cristiano: Right, maybe it was a left-over
… (fixes the PR title)
… the rendered version without the diff looks fine
… shows how to deal with a media stream
… also HLS that is mentioned in one of the examples that is not really supported yet
… the examples are not new, though, I just added a reference to the examples
Daniel: That's a good improvement, we started out with a different method, but this workaround enables you to get the data without an addtional function call
Cristiano: Any more comments? Then we can merge this
PR is merged
PR 561
<kaz> PR 561 - Extended return type of invokeAction()
Cristiano: Second PR is from Daniel, it is still a draft
Daniel: It is still a draft because we need to settle on the terms we want tou s
… we had some previous work in profile, we we have cancellable actions, some terms are coming from there
… Zoltan made some comments
… (shares his own screen)
… the profile has four terms defined
… there is one term that says pending
… we don't have a corresponding term yet, not sure if we need it
… then we also have running
… then we started off with success, profile with completed
… we also have error vs error
… Jan was suggesting to align it
Cristiano: I am also in favor of aligning it
Daniel: The work in profile has not really started yet besides this term
Cristiano: Have pending makes sense, is also more future proof
Daniel: If we have a synchronous action, then we would immediately go to completed, right?
Cristiano: Yes
… we could also have consumers that always wait for the action to be completed
Daniel: That needs to also be covered in the prose
… what we have in the PR now is that we have an ActionInteractionOutput that extends the regular InteractionOutput that provides the state
… the question I had here was whether we should be able to listen to the status of the ActionInteractionOutput
… instead of polling it
… not sure what to do here
Cristiano: So, first of all, I think we need to answer... I like the idea of extending the InteractionOutput
… but have you explained what should happen if you call the methods?
Daniel: These are supposed to return something if status or error is present
Cristiano: For listening, we should add EventEmitter
Daniel: So we could get rid of the methods actually?
Cristiano: Yes, since you have a status event
… we could also have three events and let people subsribe to these events
… this is very common in JavaScript
Jan: Could also have one event type for all state changes
… I like the idea in any case
Cristiano: Not that common I think, I would just use one event per type
Daniel: Agree
… should also ask Zoltan and the community for what is more common
Cristiano: should ask Zoltan
… should incorporate the changes after the call
Daniel: Maybe we can first describe it in a comment and discuss with Zoltan
… regarding the cancel(), I am not sure how I would be informed about that
Cristiano: Should add another event type for that
… would enable you to have a centralized place to handle this
… this might only be a software state, but I think this should be fine
… I assume if we cancel before completion, then arrayBuffer() etc. should throw, right?
Daniel: Yeah, if we cancel after completion, then it should be a no-op
Cristiano: It is nice to incorporate this feature from the TD, as we have cancelaction
… we don't have observeaction, so the implemention needs to poll
… we don't have support for queueing in TD right now
Daniel: We should be flexible to react to changes on the TD side
Cristiano: But this is related to IDs, right?
… if there is no support then we could just use the old API, should be flexible enough
Daniel: Yeah, I think it is quite well-designed
Cristiano: Hope that this will be easy to use in WebIDL
… and also in TypeScript
… need to double-check
Issues
Issue 548
<Cris> Issue 548 - Support for additionalResponses
Cristiano: I think we could start discussion this one
… I think last time we discussed this, we agreed to split this into two issues, regarding error and success responses
… the main goal is to handle the additionalResponses field from TD
… we never really talked how applications should handle this
… what do you think?
… One thing we could say is that for a runtime, if the reponse is an error we just throw that one
… but we would need to define an error type for that
… I think we already have a couple of error types already
… (opens the latest document)
… for example, we have some error types for the value() function
… like UnsupportedError
… I think we could add an addtional check here and to other functions as well
… saying that if you get an error response, you throw the error
… but we need to pick the correct error type from the list of well-known errors
Daniel: I have more a question: Are additionalResponses only for error cases?
Cristiano: Not always, there is a "success" field that allows you to get multiple success responses
… maybe this could be seen in the WoT Discovery specification
… if you check the TD of the TDD for example
… or rather Thing Model
… I think we had some examples here
… there are, for example, two possible errors that we need to support
… but there is no additional success response here
… but still, in theory, let's double-check this
<kaz> WoT Discovery - 7.3 Thing Description Directory
Cristiano: if I remember correctly, you can have multiple success responses via the success field, which by default is false
<kaz> WoT Thing Description 1.1 - 6.3.9.4 additionalResponses
Cristiano: so the main thing we have here is that the consumer should use the schema that is being referred to via the response field
… could be passed to the value function
… in the WebIDL spec we already have some error types that we could reuse, but we could also use our own
… we also need to decide whether we want to convey an error like Not Found or just use a NetworkError
… so we might need to create a mapping
… but for now we could just simply throw a network error
Daniel: I am not sure if I would expect a NetworkError
… for me NetworkError is something that happens on the network
… but I am not sure what the right choice here is
Cristiano: Could rather be a "NotConnectedError"
… or maybe OperationError is better
Daniel: That makes more sense to me
Cristiano: (Updates the issue with a comment)
… using this approach would definitely be better that dealing with all the different kinds of errors
Daniel: I think we have another issue that deals with the mapping of errors explicitly
Cristiano: I think it is issue 200
Daniel: And in the end, I don't think we can come up with a complete list here
<kaz> Issue 560 - Cover AdditionalExpectedResponses as error responses
Cristiano: Issue 560 is definitely strongly connected with 200, but maybe we should rather use an iterative approach here
… so it might be a kind idea to have the application handle this
Daniel: For me it should not throw if the data schema is the same
… so there are two cases, if the data schema is the same then you cannot really report this
… but I am wondering, do you get this as an addtionalresponse or instead of the original one
Jan: Could also have a custom error type and include the InteractionOutput as a field of that error class
Kaz: We need to think about error handling in the Scripting API in general
… with regard to different kinds of responses
Cristiano: So you are saying that we should also take into account errors like NetworkError
Kaz: Yeah
Cristiano: Until next time, everyone should through the issue once more, rather follow a bottom-up approach, deal with this issue first, and then deal with error handling in general
… we did not have time to discuss the Agenda, will deal with that asynchronously
AOB
Daniel: Happy holidays everyone!
[adjourned]