5. Actions should be used lightly; and should return a new Thing

****
Formatted Version
https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/5.%20Actions%20should%20be%20used%20lightly%3B%20and%20should%20return%20a%20new%20Thing%20.md
****

You didn't miss (#4), it's still under construction.

Points:

   - Not needed for for most Thing actions - implementation complexity
   - Pie baking machine

<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/5.%20Actions%20should%20be%20used%20lightly%3B%20and%20should%20return%20a%20new%20Thing%20.md#introduction>
Introduction

I'm not going to spend too much time on Actions. I don't have a strong
opinion on them except for that *they're an unnecessary complication for
Things* (which is a strong opinion, I admit).

There are cases where you might want to have a long lived object to track a
process. I'll put a few thoughts on this below.
<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/5.%20Actions%20should%20be%20used%20lightly%3B%20and%20should%20return%20a%20new%20Thing%20.md#actions-are-not-needed-for-things>Actions
are not needed for Things

Specifically, that what you can do with an action can just as easily as
turning on the TV.

Let's say you want to turn on the TV using an IR controller. This could be
modelled as

iot:purpose = iot-purpose:on.true
iot:type = iot:type.null

Note especially the "type.null": this means there's no expected value. It's
not like setting the channel to 32. It will do the thing, but there's no
expected istate transition.

Code wise we just do:

thing.ostate.set("iot-purpose:on.true", true)

Where the value doesn't matter. Note however we didn't use null. In APIs
this slightly more problematic because people will use null to mean "don't
change this". Which is why we use a dummy value, but we will never see that
value in the "ostate".

Now you could say "I need to track whether it happened or not". The
response:

   - you really probably don't
   - you know the action completed because the ostate will transition from
   the dummy value back to null
   - the acid test is whether the TV turned on or not: if it didn't, you
   can try again just like you do with a remote control

<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/5.%20Actions%20should%20be%20used%20lightly%3B%20and%20should%20return%20a%20new%20Thing%20.md#actions-require-server-work>Actions
require server work

If you do implement Actions, you are going to need to know whether clients
are interested in the Actions complete or not.

   - the client invokes an action
   - the server creates an action object
   - the client…

Well, we don't know. What does the client do? Maybe the client isn't
interested in the result. Maybe the client is doing some work and is going
to come back tomorrow to see whether it completed or not.

In either case, *the server has to hang on to state for an indefinite
period of time* OR *sometimes the client won't get an answer they're
looking for because the server threw away the action state*
<https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/5.%20Actions%20should%20be%20used%20lightly%3B%20and%20should%20return%20a%20new%20Thing%20.md#pie-baking-machine>Pie
Baking Machine

Now there are cases where a Thing has an Action where keeping state around
is very useful.

Consider a Pie Baking Machine:

   - I say "bake an Apple pie"
   - I say "bake a Blueberry pie"

In each case, I would argue *a new Thing* needs to be created. A "Pie
Baking Machine" doesn't have a recipe, or a "filling temperature" property,
or a "doneness" property.