Dedicated methods for DNS-SD, CoRE Link-Format discovery, and other approaches?
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 45
- Forks
- 21
- PR merge metrics
- No merged PRs in 30d
Description
Experimenting with both DNS-SD and discovery via the CoRE Link-Format in dart_wot, I got the impression that it could make sense to add dedicated discovery methods for both approaches and maybe even replace the generic discover method in this context.
As the two approaches belong to the introduction phase, the new methods could be used solely for discovering URLs pointing to Things, which could be wrapped in objects containing a url and a type (such as Thing or Directory). The results could then be followed up with either the requestThingDescription or the exploreDirectory method. As multiple incoming responses are possible when using multicast with both approaches, the two new methods could once again return an AsyncIterable which would enable an asynchronous processing of the results.
I think both approaches (and especially the case of using DNS-SD with multicast DNS) can be motivated via use cases quite well. However, I wanted to create an issue in this regard already since it also concerns a general design question if adding new methods to the WoT namespace would be the way to go here or if we risk making the API surface a bit too large. Is there maybe also a concept of sub-namespaces in WebIDL?
Another question we could also discuss in this regard concerns the generic discover method. Should we keep it as it is right now or should we maybe also replace it with more specialized methods in the future (like discoverNearbyThings or discoverThingsViaBluetooth)? From what I've seen so far when it comes to discovery with Bluetooth and NFC, I suppose that the return type of such methods could also be a URI or an AsyncIterable of URIs, right?
At some point, we might want to ask the same questions regarding DID – generally speaking, I think there is the question of which methods defined in the Discovery spec we should support directly and which should be delegated to "userland".
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the current generic discover method and the DNS-SD and CoRE Link-Format Discovery spec sections linked in the issue. Compare the proposed URL and AsyncIterable results with requestThingDescription and exploreDirectory, then document whether dedicated methods and their namespace placement should be added or discovery should remain generic.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100