| [triquetrum-dev] Triquetrum at Sandia |
|
Hello,
Congratulations on your work on Triquetrum to this point! I’m impressed and excited by the possibility represented by what you’ve all accomplished so far.
Although the corporate wheels which would allow the SAW group at Sandia to contribute to the Triquetrum project are turning slowly indeed, we are still interested in doing so, and in using Triquetrum in the Eclipse-based Sandia Analysis Workbench. To that
end I’ve been studying the current implementation, learning as much as I can, and trying to map out how Triquetrum could satisfy our users’ needs, ultimately replacing the solution we have in place now. I have a few questions about the current implementation
and future plans.
First and most importantly, the primary runtime model for us will be headless, remote operation of dataflows. Long-running workflows will execute on a server machine, while the client machine is shut down or disconnected. (In addition, some processes
will also be remote to the workflow — I.e., actors will submit remote jobs on other servers and collect the results — but I think remote processes like this are basically just a kind of actor that we’d implement.) What are current plans for implementing remote/detached
execution of workflows? Do you see this as an alternate implementation of WorkflowExecutionService? Could/should/would the remote workflow engine be OSGi-based, or an instance of “bare” Ptolemy II?
Second, and related: some actors have a runtime GUI, and there is a Ptolemy mechanism “DisplayInterface” for connecting an actor to the user interface. I see how it is used to connect various standard Ptolemy actors to the SWT UI. Is there any precedent
for remote GUIs used for monitoring components, using some kind of an RPC implementation?
Third, and maybe thorniest: the current implementation ties the editor to the runtime system fairly strongly. In the process of adding an Actor from the palette to a workflow, an instance of the actual Ptolemy actor is created. Given that I’m thinking
about our target distributed architecture, it seems to me that requiring all Actors to exist on the client — let alone be instantiable — is a limitation which would make deployment and maintenance more difficult for us. We would prefer a more data driven
approach in which the editor consumed a description of the Actors rather than the Actors themselves. Does this seem feasible? I have a vague idea that the editor’s interface to the actors could be via an access layer, one implementation of which could be direct
access like you currently have, and another could be data-driven.
Finally, for various reasons, we’re still using an Eclipse Luna target, and although we’ll certainly transition at some point, it may not be right away. I have found that I can use the current codebase in Luna with a few small changes; just wondering if
you’re open to supporting Luna, at least for a while, or if we’d have to keep a branch going.
In any case, thanks for reading this far. Any thoughts or ideas on these questions would be welcome as we start to get serious about using Triquetrum.
|