Meeting minutes
Previous Minutes
<dape> Nov-7
Daniel: names are correct
… content looks fine
… any objections?
… hearing none, the minutes are accepted
Quick updates
Daniel: skipping, just be aware that the current charter ends next January
… any other quick updates?
… ok moving on
Pull Requests
Daniel: first a minor PR
PR 440
<dape> PR 440 - chore(deps): bump minimatch from 3.0.4 to 3.1.2 in /typescript
Daniel: no issues
… we can revert it later if we find any
Cristiano: ok to merge
Issues
Daniel: I'd like to skip PRs and focusing on related issues
Issue 364
<dape> Issue 364 - Discovery API - Alternatives
Daniel: we discussed a lot about Discovery APIs alternatives
… proposed a new API
… zoltan revised it
Zoltan: let's move to the end of the discussion
… there is a blended API proposed by Cristiano
… essentially the same but with some fixes
… we need to discuss the use cases
Daniel: I've started with the discover method and then multiple functions
… now we split in different places
Zoltan: it should be fine, cause we have the constructor
… also queryAll method should not contain query URLs
Cristiano: I agree
Zoltan: I'm satisfied
<kaz> Cristiano's recent comment
Cristiano: I reviewed Discovery Spec, the proposal covers the requirements there
… there might be a corner case, e.g., DID, that I'd like to support
Kaz: if we would like to cover DID requirements in the scripting API we need more discussion with the relevant W3C group
… moreover I don't think we, the WoT WG, have to implement potential implementations for DID capability by ourselves (should be done collaboratively with the DID WG)
Cristiano: I agree
Jan: how can core-link format be supported?
… a discovery method for constrained devices
… also core resource directory
… do we need the promise in queryDirectory ?
Zoltan: it might take some time to answer
… it simplier to figure it out errors
Zoltan: when we write the algorithms we could review it
Cristiano: to add on that it is similar to fetch API, async to send and async to read the response
Daniel: the requestThingDescription method can return a TDD or TD
… I can check if it is a TDD after the method
Zoltan: do we want the application to take care of this checking and following the graph of the linked TDDs?
… queryAll should trasverse the graph
… we should be exact
… if you want the runtime to handle such automatic mechanism you can use queryAll
Daniel: the signatures of the methods will look very similar
… it might get confusing
… I would opt to not add URL parameter
… to queryALL
Zoltan: but it is an use case
Daniel: ok but I would to it manually
Zoltan: that's why I propose to add the URL in thing filter
… this would allow us to guide the query all mechanism
… I don't like to allow the manual only
Cristiano: about core-link format I think it can be implemented in another library
… about the queryAll it starts to became a big container of all introductions
… it might be complex to describe and implement
Daniel: in that case queryAll needs more than one url
Zoltan: right now we have only one way: manually
… the automatic way should handle that
Daniel: query all should be a best effort method
Zoltan: what about having a generic query method that takes an array of urls
Cristiano: don't forget that a single TDD might return multiple list of TDs that need to be merge
Zoltan: currently the queryDirectory stops to one single Dir
Daniel: what about error handling?
… what if a TDD fails?
Zoltan: best effort
… don't need to automatically stop for errors
… we don't have to report every single error
Daniel: I'm fine, but I see that we are putting too much on a single method
Zoltan: they are two different use cases
… other specs use context objects that can be configured accordingly to the use case
… manual or automatic
… the context can be controlled by the script or the runtime
Daniel: ok, but the manual is needed in any case
Zoltan: let's continue on the issue
Cristiano: may ask to write down the use case?
Cristiano: there is the case where the introduction returns a list of opaque String list
Zoltan: that's why I'd like to have it as a filter
… rather than input
Daniel: does the list on the issue looks fine?
Cristiano: ok
Zoltan: ok
Kaz: it might a nice start, but we should ask developers for their priorities
Zoltan: from the API point of view we can start using Cristiano's proposal
… we can introduce new methods if we feel like the queryAll method gets complex
Daniel: notice that we will need two different option types
Zoltan: I agree
… usally the options belongs to the method
… if they are not the same options, the definitions can be separate they can be different
Daniel: good starting point
Daniel: time adjourn the call, thank you for time
<kaz> [adjourned]