ExposedThing and DynamicThing

[h0ru5]

despite the naming should be reconsidered, we have a general question to discuss about regarding the ExposedThing and DynamicThing, where one has static interface during runtime, while the other is modifiable by methods like addProperty or removeAction

This issue is forked off from the discussion on #6 and also relates to the general contract between Things, Scripts and WoT Runtime as discussed in #2

[zolkis]

If the difference is just a policy for updating the TD, it could be exposed as a policy property (provided during construction either implicitly by the runtime configuration or explicitly by the script). Then this policy could possibly be encapsulated by the runtime...
The runtime would decide if a given TD update request can be fulfilled, otherwise return an error. It would simplify Things.

[h0ru5]

so from the viewpoint of a script dev:

the runtime would always offer all methods but give an error if I try to change an "immutable" thing (e.g. an ExposedThing which is not a DynamicThing). However, I can check that condition on with property in advance.

Right?

[zolkis]

Yes, that's the idea.

[knimura]

Let me confirm:

1. The ability of runtime for ExposedThing or DynamicThing is reflected to a policy definition in a property when generating a TD.
2. A script that tries to update the runtime by e.g. addProperty can check that condition in advance by reading the property regardless whether the script is located inside the runtime or outside of it.
3. The runtime will be updated if it has the ability of DynamicThing. If not, and still someone ask the request, the runtime will return an error.
   Correct?

[zolkis]

Yes, that's my understanding. What we don't know yet is how exactly will we expose and handle policy information - but we can start with a string or dictionary property.

[zolkis]

Of course we could keep the names, e.g. Exposed Thing (not ExposedThing), but in the API we'd have one type of object. The rationale for this would be that

• It's more generic and can cover future Thing classifications better. When we can parametrize rather than sub-class, let's do that.
• The policy may be changed in runtime (or may not). This way it's more flexible. With ExposedThing the policy would be built in. Usually we should strive to build in mechanisms, not policies, and keep policies external.

[zolkis]

Related issue: w3c/wot#310

[h0ru5]

my suggestion would be to reflect this policy as a property configurable of ExposedThing with the same semantics as

https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Configurable_attribute

This diverges from ECMAscript in the way that this is set for the whole Thing as opposed to per-property in ECMA. Reasoning is the need to also indicate if I can add a property/action/... (which I can always in ECMAscript, but I cannot always remove properties).
Modelwise this would mandate that I can chang the interface of a Thing or cannot change it - as opposed to be able to change parts of it and othr parts not.

Another option would be to have an attribute on Thing level to indicate if interactions can be added (e.g. extensible) and one on each interaction to indicate if they can be configured - closer to ECMA.

[zolkis]

In my understanding the ExposedThing interface has the purpose to define behavior and expose a Thing in "server mode". The use case is defining a Thing that is going to be exposed in a WoT RunTime.

As opposed, ConsumedThing is meant to expose a Thing in client mode, i.e. use its TD as defined, but possibly modify property values, invoke actions, subscribe to events etc.

So in my view ExposedThing is the interface through which TD changes are possible: add/remove properties, add/remove actions, add/remove events, set request handlers for all these requests etc.
Check the updated ExposedThing interface here. Rendered version here.

Is this reasoning correct, or what is the use case for fine grain limiting access to ExposedThing?

If the use case is that clients with certain privileges can only change certain set of properties/actions/events, then we'd need to attach to each property, action and event a descriptor if it is configurable for the given client -- which is a nightmare to configure when creating the Thing.

IMHO that is technically very close to actually attempting to make the TD changes and then either failing or succeeding, but there is the difference that configuration happens by the permissions of the client (out of scope for Scripting), without the need to set explicit policies at the server side using Scripting, which IMHO is a huge simplification.

However, if the use case is to set some capabilities that are valid regardless of the permissions of the client, then IMHO we should use a capability interface rather then a permission interface. In that case we'd need to expose a different interface than ExposedThing, and I guess that was the reason to propose a DynamicThing interface.

The capabilities supported by a Thing currently are encapsulated by the TD and are not exposed through the Scripting API. It would even make sense to discover Things based on capabilities (with an explicit API), but now it's encapsulated by an opaque dictionary for TD in the discovery filter. We could make that explicitly exposed in Scripting, but it would be quite complex. My argument is that it's not clear whether we really need that.

I wonder what would remain of the ExposedThing interface if we make it "static" (TD immutable). In my understanding it would be exactly what a ConsumedThing currently is (remember that ExposedThing objects implement ConsumedThing interface, IOW ExposedThing extends ConsumedThing.

So IMHO the proposed DynamicThing is the same as ExposedThing currently is, and the current ConsumedThing is the "static ExposedThing". But please check the current definitions vs the use cases.

[zolkis]

I think with PR #21 we can close this. Reopen if needed.