Hi Ernest,
First of all many thanks for the positive feedback and the
interest in using Triquetrum!
Some more info, on what Christopher already replied.
Triquetrum has been designed in a way similar to Passerelle, the
Ptolemy-based system we've been building and using within iSencia :
the core of the system is made for headless operations and different
GUIs can be integrated locally and/or remotely. E.g. we have a
web-based editor and management UI in Passerelle, workflows can be
started and monitored via REST services from any other application
and we even have a minized Swing-based UI derived from Ptolemy's
Vergil. But in the end the execution engine just needs to know where
to find your workflow definition (which is typically stored in some
XML format in files or in a DB).
Concretely :
1. We've chosen for an interface definition of the core workflow
services, so we are free afterwards to pick different ways for
remote access to the service implementations. I can easily migrate
Passerelle's REST-based access implementation. Another option that
is definitely of interest is to use the ECF framework which offers
proxies for all kinds of remote access protocols, based on the
remote services OSGi spec.
My preference would be to have an OSGi-based headless runtime,
and not to fall-back to bare Java or Ptolemy. In that way we can
reuse one common code base for everything that is not UI-related
and can keep on benefiting from all the OSGi goodies.
2. There are indeed actors that are GUI-bound. There are several
points-of-view for this, I guess, besides the info given by
Christopher :
In my point-of-view such actors should not be used in workflows
meant for headless/server runtimes. But that's because in our
typical use case with Passerelle, large numbers of workflows are
also scheduled/chained automatically and we have no guarantee that
there is even a user present somewhere at that time. And we don't
want actors popping up views all the time ;-) So we always store
(intermediate) result data and then provide ways to look at the
data at any time, also after the workflows are done. This could
e.g. be done via a dedicated result visualization workflow using
those display/plot actors, launched on-demand by an interested
user.
A remote real-time integration between a workbench and a runtime
is possible, and has been implemented by DAWN at Diamond LS, on
top of Passerelle/Ptolemy. Actors are able to open plot views,
warning dialogs etc in the user's workbench in DAWN. The editor
also shows the live progress through the workflow based on status
update events received from the remote runtime. This was
implemented via JMX. To be checked with the DAWN team about recent
evolutions, as my info is from some years ago.
Other options are possible, to be discussed separately if you
would like to expand on this.
3. My understanding is that an actual actor instance is
effectively needed during model design time, as an actor's
characteristics are defined during its construction. This has many
benefits compared to separate statically defined editor
configurations (which require duplicate work and are a maintenance
burden as well). E.g. a configuration change on a live actor can
be validated by it, it may cause it to dynamically create extra
ports, etc.
If it would be possible to use something like Eclipse update/install
to distribute actors towards your workbenches, that would seem the
easiest path forward. If we can not easily distribute extra/updated
actor bundles in your environment in such a way, this would be a
substantial re-engineering for the editor.
The Triquetrum EMF model might already encapsulate the impact a bit
though...
4. Indeed, Luna support should be feasible if needed.
And, likewise, thanks for reading through all of this!
regards
erwin
Op 9/12/2016 om 11:54 PM schreef
Christopher Brooks:
Hi Ernest,
Some comments below.
1. Headless. This is probably best answered by Erwin.
2. Remote GUIs. The short answer is basically "no, but".
Here are the "buts"
DisplayInterface and PlotterBase were part of an display
output remotely called HandSimDroid. Below is a summary
of this work:
In 2011, the HandSimDroid
project developed a prototype that allows Ptolemy models
to run under Android.
Students 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.
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/EclipseAndAWT
One of the Triquetrum bugs is to build an interface to
PtPlot, which is Swing-baseed and part of Ptolemy II. Erwin
prototyped an interface to a more Eclipse-centric plotter,
see
https://wiki.eclipse.org/Triquetrum/Extending_Triquetrum
There are a bunch of different ways to display data
remotely. These days we typically use a VNC application to
log in to a remote machine and view the data that way.
Erwin probably has some input here.
3. Actor Descriptions vs Actor Instantiation. This is a
thorny issue, here are some thoughts.
Ptolemy II has ptolemy.kernel.LazyComposite.
http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII10.0/ptII10.0.1/doc/codeDoc/ptolemy/kernel/util/LazyComposite.html
says:
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.
So, you could delay instantiation by using LazyComposite.
I'm not sure how you would edit the model composite without
instantiation.
Actor-oriented classes are not a solution in themselves,
but they could help. The Triquetrum RCP model editor does not
yet support Actor-Oriented Classes. There is an open issue
for this:
https://github.com/eclipse/triquetrum/issues/78
Note that combining LazyComposites and Actor-Oriented
Classes is very tricky and likely to have bugs.
The way I would do it is to create a facade actor that had
the ports and parameters that would be set at model creation
time. The facade actor would then instantiate a named class
at runtime and do the transfer of data. We probably already
almost do this with some of the higher-order function classes
in actor/lib/hoc.
So, I think this would require some engineering time, but
would be solvable. If Edward does not reply to this message,
then try posting to the ptolemy-hackers list.
4. Luna: Sure, I'm open to supporting Luna if it does not
break the current support for Neon. I did the port from Luna
to Neon, see
https://github.com/eclipse/triquetrum/issues/104.
The reason to support Neon is because it is the current
release of Eclipse and it seems like a good idea. I don't
think we have any other reasons to move to Neon.
_Christopher
_______________________________________________
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
