Meeting minutes
Minutes Review
<kaz> June-10
Cristiano: Let's have a look at the previous minutes, checked them before the call, they looked fine
… last time, we updated the Wiki, discussed some PRs
… some non-technical ones, discussed some aspects of the discovery method
… if there are no objections, minutes are approved
No objections, minutes are approved
Agenda Review
Cristiano: Let's see which PRs we have pending
… I think we can quickly resolve a bunch of those
… (updates the Wiki with the respective links)
PR 551
<kaz> -> Add clarifications for discover method
Cristiano: did you make any progress on the PR on the exploreDirectory method, Jan?
Jan: made some changes, needs some more work, though
Cristiano: Then we can discuss it next time
Issues
Cristiano: Then let's look at the issues
… looks like there haven't been any updates, maybe we can check next time when there have been changes
PRs
PR 556
<cris> chore: enable dark mode support
Cristiano: There was a discussion in the TD taskforce about the new ReSpec feature for enabling dark mode
… pretty trivial changes, approved by Daniel
… hearing no objections, can merge as is
Merged
Cristiano: One down
PR 557
<kaz> PR 557 - fix(ThingDiscoveryProcess): clarify usage of url field|
Jan: Just updates the documentation for the URL field of the ThingDiscoveryProcess
Cristiano: I think this is better, just improves documentation, pretty trivial
Jan: Maybe we can create a second constructor to set the url field, I think that might better
Zoltan: It is a better pattern to use a factory or an asynchronous method, we can discuss this in another context, however
… mostly depends how developers should use it
Cristiano: Where are we creating this object, in the exploreDirectory method?
Zoltan: Need to connect this to the broader developer story, we had another PR on discovery
… should do it a bigger PR if we want to change the developer story
Jan: Tried to generalize this, as the interface was used both by the exploreDirectory and the discover method
Cristiano: In my mind this should accept the url as a first parameter
Zoltan: If we want to use a url with the discover method, we might need to differentiate between directory and non-directory URLs
… are the use cases for discovering from multiple directories?
… having the exploreDirectory method as a convenience method is good from a developer's point of view
Luca: Sometimes we want to be able to just discover things around us
… we need to consider that when we are using wide-area discovery and find directories in the local network, we might just want to have the whole list compressed
… maybe we want to have two methods, one of which provides a flat list and one that provides a structured list with additional data
… we also need to consider that these methods might be asynchronous, so we might provide a query and the discoverer might decide how to process the results
… if we look at the API of the mDNS implementation, there might be implementations that go into one direction or into another, so we might need to decide in which direction we want to go
Cristiano: Maybe we can provide a default, but still make it possible to use the other
Zoltan: We can integrate it into the developer story, can define how recursive discovery works
<kaz> Example 10: Discover Thing via directory from the Preview
Cristiano: So you could get the Thing Descriptions for the directory and then follow them based on a query or you could simply get the TDD TDs
Luca: That might work with mDNS, but might not work anymore with other discovery methods such as DID or CoRE Links, the latter of which kind of works like a DID document
Cristiano: So you mean that we might lose some information when we use these two approaches
Luca: Let's recap then: We have mDNS, CoRE Link Format, DID
… we then also have well-known URIs, which we can gloss over
… we can provide configurations that can then be processed
Zoltan: So the question is then if we have Thing Descriptions corresponding with these introduction methods
… and if and how we can represent those in the Scripting API
Luca: It should always be possible to express these as Thing Descriptions
Cristiano: This is a bit weird for me, as the forms are not fitting
… as you are also not sure whether you are communicating with a REST-based interface (?)
Luca: This would force us to refine the TDD API, although I would not like implementations to support SPARQL by default
Zoltan: I think we should not assume that we always have a gateway directory, but it should always be possible to interact with it
Cristiano: What I like about this idea of a local Thing Directory is that I had some use cases corresponding with that and we would not need to specify the URL
… you would have the same API locally as for any other TDD
Zoltan: That was the idea behind the discover method
Cristiano: We can simply map the discover method to the API defined in the Discovery specification
<kaz> WoT Discovery - 7.3 Thing Description Directory
Zoltan: We can just use it via specifying a "local" string
Cristiano: We can explore this idea
<kaz> WoT Discovery - 7.3.2 Directory Service API
Cristiano: would get rid of the other discover method
Zoltan: Only thing is that the local TDD would be a singleton
Cristiano: That would probably be a detail in the algorithm, staying you would always return the same instance if you call the method twice
… you would only instantiate a new object if you are interacting with non-local directory
Zoltan: We need to also think about what we mean with discovery session and what happens if we stop it
Cristiano: We have an Events API, where we could also listen for certain events, generally the interface abstracts away the actual introduction methods
Kaz: Very important topic, need to think about how to assign IDs to individual discovery instances, also looks to me if the current Discovery specification is not concrete enough for purposes like the Scripting API, so we need to clarify this
Cristiano: Just to clarify: You mean with the ID mechanism that you need to have a way to differentiate Thing Discovery processes
Kaz: We have IDs in TDs, but also IDs for JavaScript objects for example, should be clarified
Cristiano: This relationship definitely needs to be clarified and simplified in the Discovery specification, at the moment IDs are also not mandatory for TDs
Kaz: The place where this relationship is defined needs to be clarified too (WoT Discovery spec, WoT Scripting API spec or something else?)
Zoltan: We can also have a one-to-one mapping of the Discovery specification to the Scripting API
Cristiano: We need more implementation experience, also discussed this with Ege that this could be a topic for the plugfest in November
Zoltan: I think we should make some example use cases for IoT scenarios
… the other use case is then also using it from a web page, which we don't have covered yet fully, although we currently mostly cover Node.js
Cristiano: Then back to the main topic, I think we can merge this PR
Issues
Cristiano: We have these three issues here left, which we really need to discuss next time
… for now we are out of time, though
[adjourned]