Meeting minutes
Minutes Review
<dape> -> November-14
Daniel: (Begins checking the last meeting's minutes)
… minutes look fine to me, any objections to making them public?
No objections, minutes are approved
Issues
Daniel: Since there have been no updates to PRs, we will start with the issues
Issue #364
<dape> Issue 364 - Discovery API - Alternatives
Daniel: There have been some updates to the issue
… my last comment was that the ThingFilter should be removed
… the ThingDiscoveryProcess interface does not contain it anymore in Zoltan's latest proposal
… it seems as if the latest proposal looked good to most of us
… the new API contains three methods for different use cases
… there have been more recent comments by Zoltan and Cristiano on the issue
Zoltan: Tried to describe the use cases
… was not convinced about the use-case of returning a single TD
Cristiano: discover method should cover both cases, if the URL points to a directory, then it should return a list of TDs
… otherwise we can choose what we want to return
… for the TD of the directory, you could use the requestThingDescription method
Zoltan: What is unclear to me is how to differentiate between regular TDs and TDs of TDDs
… you could let the script try out discovering from a directory and handle the error case
… I am wondering if we should let the script handle it or if the runtime should handle it
… 90 % of use cases will be Directory
… if we encapsulate it in the runtime, then we need to make sure to cover all possible use cases
Daniel: If we have a method for requesting a Thing Description directly, then we could let the directory discover method fail if a URL is provided that does not point to a TDD
… I did not really get the use case why we would need to cover both cases with one method
Cristiano: It simplifies the API
… however, I would prefer something that is more precise if we want to differentiate
Zoltan: I would suggest introducing another method for directories with the same signature at a later point of time
… could be name explore
Cristiano: I would suggest exploreDirectory
Zoltan: That sounds good to me
Daniel: We might also want to use explore instead of discoverAll
Zoltan: We would introduce a generic discover method where the URL is optional
Jan: Sounds good to me, however, I am wondering how the settings for the discoverAny method would be set
Zoltan: Needs to be defined in the algorithms, needs to resolve links, e.g., pointing to TDDs
Cristiano: I agree, we should start defining the algorithms, the context would be included in the servient, e.g. regarding how to use multicast DNS
Zoltan: The ExtendedThingFilter for discoverAny would also contain a URL
… I can provide the WebIDL in another comment, we can move on from that
Daniel: What would be the next step?
… I think we can agree on the three methods
… question to the group: I would wait until Zoltan has updated the WebIDL and others have given their thumbs up
… who could try to update the document?
Cristiano: I can try to update the document
… until the end of december
Jan: I will try to support you, Cristiano
Daniel: I will try my best as well
Zoltan: Sounds good. We will need to define the algorithms
Zoltan: Do we need a query string in the ThingFilter?
… I will comment it out for now
… (posts the new WebIDL proposal to the issue)
… (makes a couple of edits)
… it's updated now
… we can leave the query out for now since it is really complex
Cristiano: Funny thing is, that the exact query language is not defined by the Discovery Specification
Zoltan: Should we include a generic string for query then?
… might be a security problem
Daniel: I would leave it out for now
… let's assume that a Directory supports both SPARQL and JSON Path, how would you decide?
Zoltan: Needs to be decided client-side, specified in the algorithms, can be left out for now
Daniel: People could also specify their own filters
… for filtering the obtained results
Zoltan: fragment should be enough for now to narrow down the discovery process
Daniel: Discovery is a good addition for the remainder of the charter (until the end of January), we can refine the API and add other aspects like querying and cancelling actions in the next charter
Zoltan: One thing we need to do is to adjust the algorithms to the async iterator
Jan: A bit has been done in this regard, but there is still much to be done
PRs
PR 434
<kaz> PR 434 - feat: adjust ThingFilter and ThingDiscovery interfaces
Zoltan: Based on the current discussions, we can close PR #434
Daniel: (closes #434)
PR 438
<kaz> PR 438 - fix: remove mentioning of internal discovery results
Daniel: There is also PR #438 which we provides a simply fix for ReSpec errors
… can we move on with that?
Zoltan: Not sure if we still need the internal slot
Jan: Not really sure either if we need an internal slot either since from my understanding, async iterators pause the execution of the functions in questions
… maybe we can build upon other examples
Zoltan: Will have a look into this
Cristiano: Sounds good for splitting up the work
Zoltan: I will try to provide a PR with a skeleton for this thing, that we hopefully can review next time
[adjourned]