Definition of ExposedThing.register()/.unregister()

[mkovatsc]

#70 opened the discussion on how the actual meaning of the register() and start() functions.

register(), when called with a URL of a Thing Directory, helps to make Things public. This is definitely useful. The part about "a TD is generated" is too narrow; I guess discoverability is the right discussion here.

Without calling register(), the Thing would be hidden and not discoverable at all? Would it be discoverable locally (within the same Servient), but not externally (e.g., on a Servient index page or network discovery)?

register(), when called without URL, could then mean making it discoverable outside the Servient (e.g., listing it in its index or including it in the Servient's network discovery mechanisms such as CoAP multicast).

Is there a dependency on start() and stop()? Must an ExposedThing be started before registering it? Would make sense. Could register() automatically call start() if not started yet? (Less possible errors)

Any thoughts?

[zolkis]

All of these are possible. The algorithms are not specified yet.

IMHO it is up to the developer when to call start() and register().

Without registering, a Thing may be discoverable locally, if we decide to specify that way. But who would be the entity doing the discovery? Things in another WoT runtime and another connection would need to go through the WoT interface. Things in the same runtime could possibly make a discovery request with "local" option, based on a runtime-wide local directory. If so, we should specify that in the algorithm.

I have to think what the register() algorithm should do when called without a URL argument. Maybe we can enable multicast discovery. When called with a URL, it will likely send (post) the TD to that URL and returns the result.

How that TD is generated is probably subject to a separate algorithm. I agree on that.

[mkovatsc]

Without registering, a Thing may be discoverable locally, if we decide to specify that way. But who would be the entity doing the discovery? Things in another WoT runtime and another connection would need to go through the WoT interface. Things in the same runtime could possibly make a discovery request with "local" option, based on a runtime-wide local directory. If so, we should specify that in the algorithm.

The entity doing the discovery is always a WoT Client using WoT.discover(). The rest you are writing is exactly the discovery scope: local -> network/nearby -> directory

For WoT Clients in another WoT Runtime, register() must have been called, with or without URL to discover the ExposedThing. Multicast discovery is only one implementation of network discovery (for which register() would need to be called first to include that ExposedThing in the results).

We might want to review the DiscoveryMethod enum at some point...

[zolkis]

Looks like we agree.

[mkovatsc]

Noting down an idea. What about:

let thing = WoT.produce(myTemplate)
               .addProperty(pInit)
               .addAction(aInit)
               .setActionHandler(aHandler)
               .expose();

where expose() makes the Thing available and optionally registers it at a Directory if a URI argument is given? Probably we need also the inverse to "decomission" an ExposedThing.

This would also solve the start()/stop() issue.

[zolkis]

Yes, this looks good. Too bad chaining is not supported in the current API (all functions are void).
However, we need to define the algorithm for expose(). The naming itself is fine with me and is consistent with the ExposedThing name.

[mkovatsc]

chaining is not supported in the current API (all functions are void)

This is something we should still fix, as this was possible in the previous version and there is no reason not to support it.

[zolkis]

I will do that (re-add chaining support) now, as it's a trivial change. @danielpeintner, @knimura, is that OK?

[knimura]

Yes, fine. We can discuss later if necessary because looks it is a matter of preference.

[mkovatsc]

Chaining was fixed in the last WD release.

Left open is the clear definition of exposing a Thing from the Scripting API. I still recommend the .expose() mechanism as described above.

[zolkis]

Should be fixed by #113.