Simplify discovery methods

[zolkis]

Right now, supported DiscoveryMethod strings are any, directory, local, multicast. In earlier drafts we also had direct, and #222 considers that use case as well.

I'd like to propose removing local and multicast, and re-add direct, with any remaining redundant (removed as well).
So in the end we'd have support for direct and directory methods.

We had a call with @relu91 about this and we agreed about the following.

Reasons to remove local:

• It would be very complex to define what exactly it would mean. It could mean sensors/actuators available on the same HW or SW or WoT runtime. Examples: local accelerometer, various thermometers, gyroscope, proximity, ambient light sensor etc, in general covered by the Generic Sensor API suite. Or NFC adapter, or things locally connected via Bluetooth, etc.
• It would be complex to implement. How a WoT implementation would find all these and how does it expose them as Things?
• This functionality should better be implemented in SW package(s) that need to implement a subset of the locally available sensors and also add Thing Descriptions and (or expose via) a local Thing Directory.
• The Scripting app, and implementation could then find and integrate a local Thing Directory given its URL.

Reasons to remove multicast:

• There is some confusion what does it exactly cover. Multicast discovery is usually used in phase 1 discovery (provisioning time), but in some protocol suites also in operational mode. It is unclear what an implementation should do when receiving multicast from an application. Right now the spec is too vague about this: "discovering Things in the device's network by using a supported multicast protocol." It sounds like "discover anything, but with a multicast method". Which leads to the next argument:
• So far we don't have a strong use case for supporting it. Therefore we can test to remove it and re-add later when there is a use case for it.

Reasons to re-add direct:

• We have a use case for it in many protocol suites. If an app provides a URL, that is pointing to a Thing Directory, it might provide different things in direct mode (e.g. the TD of the directory itself) vs all the TDs contained in the directory (if directory was provided as method).
• Provides an more convenient WoT-specific way to fetch a TD from a URL (as opposed to using the Fetch API).

Counter-arguments to re-add direct:

• Since discovery in Scripting currently returns TDs, it would be the same as fetching a TD from a URL. Although in the simple cases it would be more convenient for apps to use discovery vs Fetch.
• Using discovery for a "convenient fetch" sounds a bit awkward.

Reasons to remove any:

• It is not needed any more. The app has to know if it wants a TD from a URL, or if wants to get TDs from a directory. The directory method could be the default, as the direct method is more specific and it's better visible in the code explicitly.

Please chime in with opinions. I can provide a PR after the discussion settled.

[danielpeintner]

I think the goal should be to align with what the Discovery task forces comes up with. At the moment it seems to be

• direct and
• directory

@zolkis additionally you are proposing to keep any which seems to be there to indicate both the aforementioned, right?

[zolkis]

No, I have argued that we should remove any. See my first comment.

[danielpeintner]

No, I have argued that we should remove any. See my first comment.

Sorry, I missed that part.

I am still unsure whether any might be of help. Are there cases where I don't mind (or put differently: I do not know or mind getting a TD from a URL or a directory)

[zolkis]

Are there cases where I don't mind (or put differently: I do not know or mind getting a TD from a URL or a directory)

I don't think so. As I said in the first comment, a script should know if it wants to list a directory, or wants to access a specific thing. If not the latter, then the former. Hence directory is the default.

[danielpeintner]

Scripting Call 2021-04-12

• @zolkis will work on a PR

[zolkis]

Some other concerns recorded during the call:

• the Scripting API for discovery provides full TDs and all filters are meant for limiting the result set.
• the Discovery API (network API) will support queries to return just a part of a TD (also conserving network bandwidth). This use case is not supported yet in Scripting. It is a question how will it play together with the current API.
• TD streaming in the response is not exposed to applications, i.e. the implementations need to encapsulate this.
• Scripts could use the Fetch API to make queries to directories (after fetching the TD of the directory), then manage sub-TD responses. They can use the higher level Scripting API for getting full TDs.

We should think about integrating the missing use cases when they are mature and established.