Add use cases. Refactor WebIDL.

[zolkis]

WebIDL was updated based on comments in #3.
Added some of the use cases mentioned in #6.

[h0ru5]

to avoid confusion with the interacion pattern "action" (of a thing) , could we say "a callback" or "logic"?

[zolkis]

Yes, we could use something different. Originally I've used "hook", since it serves a special purpose (server side code executed before/after the implementation invokes an action registered by a client).

However, I have deliberately changed it to "action", since the signature may be the same as for registering an action, and shouldn't it be part of the TD like Actions are?

So if we use a different word, e.g. "hook", it needs to be added to the interaction list, together with Actions, Properties and Events.

Another question: could we model this use case with special events that are triggered locally by a property change or action invocation?

And finally, as also asked in the issue: is there an other way to fulfill the use case?

[h0ru5]

to avoid confusion with the interacion pattern "action" (of a thing) , could we say "a callback" or "logic"?

[zolkis]

What about the following:

• for request handlers we use single callback (to handle requests like retrieve TD, run Action, add Event listener, etc)
• for hooks we use built-in events, like on("actionrequest"), `on("propertychangerequest") to which multiple listeners can be attached. In the use case, we can use the term "observe", like "Observe requests for invoking an action", and "Observe a request for property change". The effect is that after a property is changed or an action is invoked, listeners are notified in order to update their business logic.

However, I still fail the understand the use case for the hooks. These hooks are only used by the same script that defines the server Thing. Why cannot the logic that goes into the hooks go directly into the request handlers?

[zolkis]

I have reformulated the use cases and moved all observation use cases to consumed Thing. The misunderstanding probably came from the fact that ExposedThing also implements ConsumedThing and in the Current Practices they are just dumped together.

[zolkis]

@knimura @h0ru5 could you review again, please

[zolkis]

Added request handlers to ExposedThing and consolidated use of dictionaries for properties, actions and events.

[zolkis]

Based on this comment I am merging for now. If there is feedback, let's raise them later.