Allowing for dynamic instantiation and removal of a Thing

[kehusa]

In order to deal with dynamic environments where things pop up and disappear, it would be a very useful feature to allow dynamic instantiation of a Thing. We would the be able to model the state of the dynamic thing using "conventional" thingml semantics. This is a much wanted feature from the Tellu use-case.

[brice-morin]

Ok we need to think about that in depth, but what about having a new type of action (which you could use in a state machine, in a function, etc) like this:

instantiate myDynamicGroup {
  instance myInstance : MyThing
    set myInstance.myParam = 12
  instance myInstance2 : MyThing2
  connector myInstance1.myPort => myInstance2.myPort
}
......
destroy myDynamicGroup

Basically being able to declare and invoke a Configuration from within an action, keep some reference to those dynamic configurations and have another action to destroy/remove a given dynamic configuration.

One additional concept we would need is to be able to refer to this instance, as typically the thing/instance instantiating dynamic configurations would be connected to instances in those dynamic configurations.

Also we have to assess how feasible is it to actually support those dynamic configurations in the different compilers.

@Lyadis @ffleurey @oysteinh what do you think?

[brice-morin]

OK, I implemented the following concepts and syntax:

 create dynamic {
     instance this : TimerJava //this is a convention, maybe we should enforce a this instance in the language
    instance a : A
    connector a.pout => a.pin
    connector a.pout => this.timer
} : getID()

....

destroy getID()

Basically, as mentioned before, it is pretty much the same syntax than normal/static configuration. We need to call a function (here getID, but can be anything, with any params (typically sensor name, etc)) that is supposed to generate a unique name for the dynamic configuration. create will create and start the configuration.

I propose to use this as a convention to denote the current instance. I tried to implement it directly in the language, but it complicates things quite a bit.

For the destroy, we just call the id function. destroy will stop and destroy the dynamic configuration

Currently none of the compiler support those concept. I will support those concepts in Java and JS compilers, probably in January.

Anyway, all of those dynamic features are implemented in a separate branch in the ThingML repository and will not be released and integrated in HEADS IDE until after the HEADS review. But I'll make available some prototypes so that you can try.

[brice-morin]

OK, after some discussion with @ffleurey we might have found another approach, which is lighter (could easily be implemented only with some annotations at first, and minor modifications in the language afterwards), but gives less freedom. It should however be enough for most cases, hopefully. You can find an example here.

And the good thing is that it is very similar in the way it works than Linux forked processes (hence we do not need to justify why we invented something new).

Currently, not supported by any compiler, but it should be easy to support in all major compilers (Java, JS, Linux C), but probably not in Arduino C in a short future.

[brice-morin]

OK, after several discussions we will introduce the notion of session. A session is basically a dynamic region:

thing Gateway {

     property id : Integer = 0 

      /** Thing's attributes are copied into the sessions at fork time i.e., they are not shared
     A forked session will have its properties initialized with the value of 
     parent's properties at fork time.
     Parent and forks can update their own copies of their properties, without interactions.
     The only way to exchange information with sessions after fork-time is via message passing e.g. 
     through an internal port.     
     Session cannot be explicitly killed (for similar reasons why Thread.stop() has been deprecated in Java) from the outside: they have to reach their final state
     so that they can be terminated (and garbage collected, etc). It is possible to suggest a session
     to terminate e.g., by sending a message that will trigger a transition its final state
    */

    statechart behavior init Init {
        state Init {
            on entry do
                var id : Integer = ....
                fork s //here is how we instantiate a session 
            end 
        }

        session s init Init {

            state Init {
                 transition -> Stop
            }

            final state Stop {//we kill session by making the session reaching a final state

           }
        }
    }
}