Meeting minutes
approving past minutes
<kaz> vF2F Day 6
<dape> March-8
Minutes approved.
vF2F recap
<dape> https://
Daniel: we need to approve the minutes
Zoltan: we had 3 action points: meeting with Discovery TF, Security TF and work with TD TF on ExposedThing
Zoltan: we need to allocate meetings and make tracking issues
Minutes approved.
<cris> daniel: back to agenda, no pending PR
<cris> ... I added a list of issues that were recently updated
<cris> cris: can we discuss the possible meeting with the others groups?
<cris> daniel: ok
joint meetings
<cris> daniel: about TD joint call usually all of us are there
<cris> ... we should talk about how to create an expose thing from a ThingModel
<cris> ... we have a tracking issue for this
<cris> ... it is still work in progress
<cris> ... the other thing is about the validation. For example, title is mandatory or not
<cris> https://
Cristiano: about generation of Thing Models
… we can do it in 2 steps
… Thing Model --> Partial TD
… then we can use the partial TD in Scripting
Daniel: I see some problems, e.g. title
Cristiano: we can discuss this during the next call, needs discussion in the TD call
Daniel: creating tracking issues for TD
… or checkboxes for TODO list
simplifying discovery, #311
https://
Zoltan: discovery methods will be direct and directory, by default directory
Daniel: when making a discovery query, one could get a direct TD (fragment) or a directory
Cristiano: queries are not just filters, but you can select parts of the objects
… for instance just the title
… that is problem with Scripting API
Daniel: you can ask a directory for TDs with a certain title
Zoltan: what can you do with a partial TD? what's next?
Cristiano: it's like database queries, and optimizes bandwidth
Zoltan: that can be done in a script, but doesn't need to be the Scripting API
Daniel: we can make query from Scripting
Cristiano: we could put constraints on those queries
Daniel: in the implementation I would just pass it to the app
Zoltan: we need to separate the use cases, understand them and then design an API for them
… first we should have the API to get TDs
Daniel: the discovery conformance class is separate, no need to create ConsumedThings
Zoltan: the dicovery TF spec is too complex right now, we should wait for crystallized use cases
Cristiano: an app could get the TD of the directory, then figure out the rest from there
… the use case of returning a fragment of TD should be done with the current API
Daniel: discovery API provides a TD, in node-wot we could use the TD of the directory to handle it
Zoltan: that is the vanilla API and it's possible, but we could have a better API
Cristiano: agreed
Cristiano: handling directly directory TDs is very complex, we'd need a better abstraction indeed
Zoltan: proposing small steps, implement them, play with them on plugfest, then move on
Cristiano: agreed with that direction
Daniel: makes sense
Zoltan: will create a PR based on #311
security
Cristiano: provisioning security
Zoltan: a script should not be able to provision security. It needs a different API meant for another level of security for the runtime.
… it belongs to the Scriping task force, but a different deliverable
Cristiano: right
Daniel: CA is working on a PR, so how should we continue
<dape> https://
<dape> https://
Zoltan: we should make focused proposals on the security provisioning use case, developer flow and API
Daniel: we also need to think about what we can do in the core API
Cristiano: developers could know what security schemes are supported
Zoltan: that is a valid use case for ExposedThing
Daniel: if we expose a thing node-wot adds all supported security schemes
Cristiano: yes, and if something is not supported it can include info for that
Daniel: we need to adjourn
Meeting adjourned.