Meeting minutes
Minutes
<kaz> Jan-17
Daniel: The old minutes look good to me
… we discussed lots of issues
… are there any objections to making them public?
There none, minutes are approved.
PRs
PR #367
<kaz> PR 367 - Correctly reference/use definitions
Daniel: PR fixes references and definitions
… Zoltan and Cristiano have already approved it
… there are currently 14 ReSpec warnings which will go away with these simple changes
… Are there any objections?
There are none, dp proceeds with merging the PR
PR #368
<kaz> PR 368 - resolve ReSpec warnings
Daniel: This PR is similar, tries to resolve some ReSpec warnings
… warnings result from a flag indicating that we are on REC track, I removed the flag
… there are also unused definitions (user-agent and JSON-LD), which can be removed/replaced
… Zoltan suggested referencing an existing user agent definition as well
Cristiano: Is only the reference removed or the whole sentence?
Daniel: Only the references/<span> tags are replaced
Cristiano: Why not removing the references alltogether if we are not using them?
Daniel: JSON-LD is currently not mentioned in the document, your argument is valid
… we could remove it
Cristiano: My proposal would be removing it as long as we don't find a place where we could use it. As long as this is not the case, I would prefer removing it
Daniel: Good point, removing it would not hurt us
Kaz: Even though the current draft does not mention it explicitly, the document uses some of the vocabulary (title, @context, ...)
… Consumers check validaty based on the JSON-LD vocabulary, maybe we should add references
… section 6.2 mentions JSON-LD vocabulary, for example
Cristiano: Why don't we explain this relation in the Thing Description type?
Kaz: as the starting point for today, we could add an editor's note
Daniel: To get rid of this warning, we should state somewhere that the term comes from JSON-LD
… I would suggest the following: After the call I can go over the document and add in that JSON-LD vocabulary is used
Cristiano: In the ThingDescription type, we could mention the JSON-LD vocabulary, and then we would be done
Daniel: Looks good to me, this would also be my preferred solution for now to resolve the warnings
… I will update the PR and will mark it as ready once I feel comfortable
… then we can discuss it again
Issues
Issue #364
<kaz> Issue 364 - Using a callback-based approach for Discovery?
Daniel: I tried to make up my mind regarding this issue and I think it aligns well with the existing Subscription API
… Jan also proposed adding a stop parameter to the callback
… this could be used as a shortcut to the ThingDiscovery object
jr: The stop callback would serve as a way to avoid an explicit null check in the discovery callback, but it probably isn't actually needed
Cristiano: I like the new design, but we have to keep in mind two things: At the moment, we only have direct and discovery as method. I am wondering if it makes sense to use this new approach if we only have direct and directory methods. Should we continue this road or should we stop with what we alrady have?
… should we stick to phase 2 or should we include phase 1 as well?
Zoltan: The current state of the API is shaped by projects like OCF and other projects which also Bluetooth and broadcast
… in some specs like OCF it is required to have the discovery in a different security phase
… phase 2's whole purpose is only to fetch TDs
Cristiano: I think this makes sense, but then the current API is not needed as we are just fetching TDs
… both the directory and the direct method take a URL and return TDs
… If we use a fetch method instead it should accept any WoT supporting URL scheme
Daniel: I agree that just using direct and directory methods does not have that much benefit, maybe we do not need the discover section at all (?)
Cristiano: I would keep it but we should probably change the section drastically and align it more closely with the Discovery API
… and just explicitly define a direct and a directory method
<kaz> Related issue 222 - Possible alternative design of Discovering API
Zoltan: What happens if you don't have a directory server?
… then you must give it a URL?
… I would prefer making the API more generic and not hardcode discovery methods
Daniel: I can see pros and cons for both approaches, the ThingFilter approach might need an extension of parameters in the future
… parameters of concrete methods are more clearly defined
Zoltan: Would you use a callback with concrete methods?
Daniel: We should align with Subscription approach/proposal by Jan. Could you revise your approach?
Cristiano: I will try it out, I will add it to my own issue
Zoltan: We need conformance classes for this
… need to check what we are exposing
Issue #219
Daniel: They are discussing it in the TD group
… other issues got updates as well, we will discuss them next week
<kaz> [adjourned]