You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in #18 a way to migrate FunctionBlocks from one to another would be nice. This probably can't be done if the block isn't designed for it, but we could use a marker to let the programmer specify if it is possible. The general process to migrate a FunctionBlock should be:
tell the FunctionBlock that it will be suspended. From now on reject incoming values for the inputs.
serialize the FunctionBlock and send it to the other Module
let the other Module load all classes. Maybe we could include a list of classes needed for each FunctionBlock. This list is already created for deployment, shipping it with the classes would be easy as would reevaluating the data from the classes stored in the Application's class loader
on the new Module deserialize the block and tell it to resume work. From now on accept values for this block
Maybe having suspend()/resume() methods could be enough of a marker.
The text was updated successfully, but these errors were encountered:
We could use parts of the BlockMessage interface. It already provides basic capabilities for starting a (de)serialized block. Maybe we can also use parts of the serialization code in deploy.
Yes, we should be able to just use BlockMessage to move the Blocks between modules, but that may not work for all blocks, so having a way for them to react to a migration would be nice.
As mentioned in #18 a way to migrate FunctionBlocks from one to another would be nice. This probably can't be done if the block isn't designed for it, but we could use a marker to let the programmer specify if it is possible. The general process to migrate a FunctionBlock should be:
Maybe having
suspend()
/resume()
methods could be enough of a marker.The text was updated successfully, but these errors were encountered: