Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate FunctionBlocks #32

Open
Patagonicus opened this issue Aug 10, 2013 · 2 comments
Open

Migrate FunctionBlocks #32

Patagonicus opened this issue Aug 10, 2013 · 2 comments

Comments

@Patagonicus
Copy link
Member

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.

@schnabeltrei
Copy link
Member

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.

@Patagonicus
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants