javagl / flow Goto Github PK

The flow-io package currently contains a very basic (hand-crafted) set of classes for reading/writing FlowWorkspace objects as XML. (This was created in 2012. As an alternative today, one might consider JSON...)

Regardless of the exact file format, there are some details that make the serialization of the flow difficult. This mainly refers to the non-serializable state:

A Module instance may not be serializable at all. It might have been created on the fly, by wrapping a Function or even a Method. Additionally, it may have an associated visualization (GUI components), in form of ModuleView objects.

Therefore, the only thing that can go into the file are

• The state of the Module that is explicitly marked as such. This is stored in the Module#getConfiguration object, which is (for the purpose of serialization) assumed to be a Java Bean, and written with an XmlEncoder.
• Information about the ModuleCreator that creates the Module and the ModuleView instances

The latter is currently accomplished very pragmatically, and not very flexible, by using the ModuleCreatorInstantiator. The XML file may contain a certain (unspecified) String that is passed to this class, to create the actual ModuleCreator instance. For more flexible, custom ModuleCreator implementations, this concept has to be generalized.

There currently is a very simple FlowExecutor interface that just receives the Flow and executes it in an unspecified way.

The current implementation (in the DefaultFlowExecutor) simply executes all modules, in "wavefronts": At each step, it executes the set of modules whose predecessors already have been executed.

There should be more flexibility for the actual execution. There could be other implementations of the FlowExecutor interface, but these could not cover all application cases. One application case that should be supported is a mode where each module is waiting for input, and immediately starts its work when it receives an input.

This may be particularly useful for flows that include visualizations: When there is, for example, a visualization of a scatter plot, then the user may have the option to select a subset of the points in the scatter plot, and the subsequent flow should be executed with this new selection.

(Note: This is strongly related to the Link interface and its current implementation. The current DefaultLink internally stores a blocking, one-element queue. When a module provides an output object, it is passed to the Link, and stored in the queue. Subsequent modules will fetch this object from the Link, and use it as their input)