Definition of ExposedThing.start()/.stop()

[mkovatsc]

#70 opened a discussion including start() and stop().

I guess we all agree that start() and stop() are required to avoid serving "unfinished" Things. Still, please +1 or comment this.

The only aspect to clarify would then be its relation to register().

[zolkis]

OK, we repeat things in more and more issues. See the comment made in #75.

[mkovatsc]

Yes, but #75 is about the semantics of (un)register().

So do you agree with my sketch for start() and stop()?

I want to see here a rough algorithm definition to be sure we all agree on the two functions start() and stop(), and can close this particular issue.

[zolkis]

They are trivial. Start handling requests and stop handling requests. That's it.

[mkovatsc]

Then how is the behavior when I call addProperty() on a started ExposedThing?

Do I need to stop it first for editing?

[zolkis]

It is an implementation problem. On most implementations one could add a property without disturbing current functionality, but the TD needs re-registering. IMO it should be left to the script how to define this. The implementations should just ensure transactional integrity.

[mkovatsc]

But you have not even an error mechanism defined in case the implementation does not allow it. Thus, this must be covered by the Scripting API to get deterministic behavior in different runtimes.

If re-registering is needed, register() now has a different meaning again: it is not enabling discoverability as discussed in #75, but again has this touch of writing the TD to a file.

I thought for this you want to define the "algorithms" behind the functions?

[zolkis]

Yes, the algorithms should specify all of that.
The observation about failure case (I assume for addProperty) is valid.

About register,

• without registering, an ExposedThing is discoverable only locally/on multicast discovery
• registration means posting the TD to the specified URL, and a prerequisite of that is generating a TD (not necessarily writing it as a file).

So if the TD is changed, it should be updated everywhere it was registered, but this is the responsibility of the solution (application script), as well as invoking stop() and start().

[mkovatsc]

Why is it now discoverable on multicast discovery? I guess you forgot the case where register() is called without URL.

And also registration updates (see CoRE Resource Directory which defines the basic interfaces of the Thing Directory) can be handled without a call from the script.

[zolkis]

Why is it now discoverable on multicast discovery? I guess you forgot the case where register() is called without URL.

Right. It's only locally discoverable without registering. However, I see very limited use case for that. A script that defines an ExposedThing has not many reasons to discover it locally. And we have not defined yet how multiple scripts should be run in the same runtime. If it's single tenant runtime, and the Thing to be discovered is part of the same solution, the solution doesn't need local discovery to know what Things it has defined. Multi-tenant runtimes are debated in security TF. How one solution should be dependent on another solutions Things that are not registered, but assumed to be run in the same WoT runtime... it is beyond my imagination why someone would rely on such a scenario.

[mkovatsc]

Well, I tried to make sense of the register() and unregister() calls. If there is no use case, I am happy to drop the register calls and rather do a myThingDirectory.invokeAction("register", myTD)... based on a TD for the Thing Directory, as Directory registration is the only real purpose now...

[zolkis]

The no use case is for invoking register() without arguments, so we could perhaps drop the optional from the url argument. We can also discuss more about these in the F2F.

[mkovatsc]

The current ED still does not answer why start() and stop() are needed. Being trivial does not mean they have a purpose. Requiring developers to call start() is just an inconvenience.

In the discussion of the Prague target, we discussed that changes on the ExposedThing will each be implemented as a single transaction. Hence, there is no technical need for stopping an ExposedThing.

Can we drop start()/stop()?

[zolkis]

No, it remains open and will be handled when algorithms are specified.

[zolkis]

The reason they are separate is they are doing different things:

• start()/stop() will just start/stop servicing requests
• register() is a network operation and has a different algorithm.

[mkovatsc]

So for Prague, do users of the API need to call start() before an ExposedThing is reachable or does it start automatically?

What are the use cases for temporarily stopping request handling, given that we have atomic transactions for changing the Thing?

[zolkis]

We have not defined the algorithm yet, but yes, that is the idea: start() needs to be called explicitly.

Stopping a Thing might be desired when TD changes are applied to it. It should be up to the application script to decide when.

[mkovatsc]

The last PlugFest again did not show the requirement for start()/stop().

@knimura @mmccool @mjkoster Have you seen this requirement?

[zolkis]

Obsoleted by #113.