| Re: [triquetrum-dev] Triquetrum at Sandia |
In 2011, the HandSimDroid project developed a prototype that allows Ptolemy models to run under Android.We looked at SWT and at the time it did not work for us under Mac OS X. See https://chess.eecs.berkeley.edu/triq/wiki/Main/EclipseAndAWTStudents from CMU:
- Anar Huseynov
- Justin Killian
- Ishwinder Singh
worked with Bosch researchers:
- Elizabeth Latronico
- Charles Shelton
and Berkeley researchers to re-architect a portion of Ptolemy II so that models could run on a server and be displayed on a low-powered handset.
The code for this effort is in
- $PTII/ptolemy/ptserver
- $PTII/ptolemy/homer
- $PTII/ptolemy/actor/gui and $PTII/ptolemy/plot were modified to support displaying on a remote machine.
A marker interface for lazy composites. A lazy composite is a CompositeEntity that does not automatically populate itself with contained entities and relations when it is instantiated. It does populate itself with attributes and ports, but the contained entities and relations are not created until they are explicitly requested.Note that a class that implements this interface cannot have parameters whose values are expressions that refer to contained entities or relations or attributes contained by those. This is a rather esoteric use of expressions, so this limitation may not be onerous.
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.
_______________________________________________
triquetrum-dev mailing list
triquetrum-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/triquetrum- dev