Add use cases

[knimura]

Wouldn't it be necessary to have the following use cases?

[ConsumedThing]

• Currently only mentions consume remote thing.
  use case for local string/object?
• Use case for remove all listeners.

[ExposedThing]

• Use case for remove all listeners.
• Use case for unregister a thing.
• Use case for start.

[Programmable]

• use case for add a handler which is called when an action is invoked.
  this is different from use case for addAction which only defines name and parameter/return type for action.
• use case for clear ActionHander
• use case for add a handler which is called when a property value is updated
• use case for multiple add PropertyChangeListeners
• use case for remove a handler which is called when a property is updated
• use case for remove all handlers which are called when a property is updated

[zolkis]

For ExposedThing:

• start and stop is already there in the use cases.
• register and unregister seems to be missing, we need to add.
• removing all listeners means removing other clients from observing a Thing. This is very invasive and until we have a solid security model, IMHO should not be encouraged. What is the application use case for this scripting use case?

For ConsumedThing:

• IMHO it should make no difference in the API if the consumed Thing is local or remote; it is identified by a URI. It's the bindings/implementation that should care about local optimization, IMHO we should not create a local and remote API for consumed and exposed things. Arguably, if there is reason for local APIs, they should go in a different spec, and appeal to WoT bindings/implementations.

Other

• what is the application use case for action hooks? observing/deflecting by other clients when an action is triggered by some other client? So every client can register an action hook? If so, IMHO we need to think it over find a better abstraction for this (and the pattern in general, not only including actions).
  If this is for the local script, IMHO hooks are not needed, since it can be done locally in script.
  So, code examples would be helpful in order to clarify what do we want to achieve here.

[zolkis]

Should we add flags to an ExposedThing whether they are meant to be discoverable, observable, etc? (policies)

[zolkis]

As mentioned here I still don't see the value of server side hooks on property changes and action invocations.

Observing property changes and action invocations should be part of the client API.
On the server, since the hooks would be defined by the same script that defines the server Thing, that logic could go directly in the request handlers.

Could someone provide code examples for why server side hooks are needed?

IMHO the use case is already covered by the client use case
"Add a listener to an event."
Property change and invocation of action could be default events defined on the server.

[knimura]

Latest use cases seem fine.
Lifecycle of script could be added if we agreed on.

[h0ru5]

I have one little detail:
For exposing things, I'd like to group/seperate the cases to add/remove properties/actions etc. from the cases to attach listeners, change properties etc.

rationale:
on consrtrained runtimes or when constructing a thing from a TD, it might be the case that you can add handlers and interact with an exposed thing, but not add/remove properties/actions etc.
That concept was discussed only a bit so far, as we tried to separate ExposedThing (exposed and not modifiable in structure) and DynamicThing (exposed and modifable)

[zolkis]

Yes, this might also be a good thing from security point of view: Things might want to define different policies to these types of access.

[knimura]

"Issue #2"

the runtime hosts one ore several things and runs scripts.
Things in a runtime share these
In this case, "DynamicThing" could consolidate these ?

[knimura]

In the above case, "DynamicThing" could consolidates these ?

[h0ru5]

Taking discussion on "DynamicThing" vs. "ExposedThing" to an own issue