Meeting minutes
previous minutes
<kaz> Aug-30
Daniel: we tackled some PRs and looked on label categorization.
… they look ok
… any concerns?
Zoltan: none
Daniel: minutes approved
quick updates
Daniel: just keep in mind that we might need to decide whether to publish on Semptember
Open PR
<kaz> PR 333 - Label Table
Daniel: minor update
… Zoltan and Cristiano are already on board
… just a link to the label section
… good to go
Cristiano: are you planning to add descriptions to the current list of labels?
Daniel: right, adding an issue to keep track of this
… any other comments?
<kaz> kaz: +1 to add descriptions
issues
Daniel: essentially there are two issues
Op values
<dape> New op values (queryaction and cancelaction), https://
Daniel: it's about query action and cancel action
… in the td repo there's an open pr for queryaction and cancel action operations
… our issue is just a heads up
… probably we'll add two new methods in consume thing for those two new operations
… any comments? other alternatives?
Cristiano: maybe we could return an handle and there add the functions to handle these new ops
Daniel: we have to keep in mind that we should not break the current API
Cristiano: btw I am not sure if the new operations will be for a dynamic queue of actions or just for a static single action
Zoltan: also not all servers might support this mechanism
Daniel: is it planned for 1.1?
Cristiano: yes
Daniel: ok at least we have already two possible solutions in mind
<kaz> related TD PR 1208 - Add queryaction and cancelaction operations - closes #302
NotFoundError
<dape> Issue 334 - NotFoundError is not used
Daniel: in some situations the call expect an affordance name as argument
… what happen if the property name is not found
… the algorithm does not explain it
… who can check this issue?
Cristiano: I could propose a simple proposal of how it would look like
… but I might not have time to check the security concerns
Daniel: no big deal, I'll review it later
Cristiano: is NotFoundError standard?
Zoltan: I think so
Daniel: regarding this they are located on DOM exceptions
… Ege also asked for a better list of which errors might be thrown
<kaz> related Issue 200 - Error Handling
Cristiano: the PR will only be about client side checkings not networking errros, right?
Daniel: yeah
Cristiano: about networking... are we planning to tackle error reported from binding implementations?
Daniel: I had some use cases
Zoltan: the problem is that applications in wot should not have knowledge of the specific binding
… we should keep this simple
Daniel: I agree on one hand side
… people will look for ways to know what is happening on the network level
… also we have a formIndex, isn't already a protocol information?
Zoltan: I see it as a temporary feature to cover corner use cases
Daniel: I like this feature because it can open to complex application behavior
Zoltan: yeah, but it requires the application to go down one level in the abstraction layers
… we might re-visit this in the future
… text based search in the discovery?
… should we represent bindings at all in the scripting api?
Daniel: currently no
Zoltan: one design choice could be having an endpoint for each binding
… but this will lock all the interactions using that specific binding
Daniel: development time requires formIndex
Zoltan: we don't have really that use case in the scripting api
Cristiano: we used formIndex to specify a form with a particular secuirity scheme
Zoltan: we didn't really analyze the use case...
… actually we didn't even create it
Daniel: I think it was there, otherwise we wouldn't add the formIndex
Zoltan: we make an issue to discuss the use case of form index
Cristiano: this might be loosely related to security management
Zoltan: we might find good use case scenarios for users, cause it is pretty basic
clean f2f issues
<dape> Clean-up F2F issues, see https://
Daniel: we had those list of issues to be discussed in the f2f
… those are still valid
… how do you think is better to relabel them?
Cristiano: I would start from removing the f2f label
<kaz> e.g., Issue 219 - Discussion about read- write-/multipleproperties
Daniel: ok I'll look into it, I may also comment with relavant information
<kaz> [adjourned]