User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
FYI,
If you use OSGi Services to implement your services, then one
thing of likely use to you would be the OSGi Remote Services
specification/standard (chap 100 and 122 in OSGi Enterprise
spec). Since before the beginning, the ECF project has provided a
CT-tested impl of this standard [1]. I participate on the EEG,
which defines the RS specifications.
Using Remote Services would make it easy to distribute your
services...in a standardized and open way. Other advantages for
you and consumers of such services:
A) Leverage existing and new distribution systems. For example:
existing or new REST APIs [2], new transports like MQTT [3], or
websockets [4]. ECF Remote services would allow you to use any
such alternative distribution systems *without modifying either
the service API or the implementation*
B) Flexibility to use non-Eclipse-based OSGi tech (e.g. Karaf,
many others) for server implementation. Even use services exposed
by non-OSGi, or even non-java servers [5].
C) All technical advantages of OSGi services (dynamics, injection,
service versioning, service dependencies, separation of concerns,
service-level security, etc), and for Remote Services
(extensibility of discovery and distribution, standardization of
remote service meta-data, standardized management agent) for
free. See [2].
If help is desired for designing or implementing such services to
allow for eventual distribution please let me or other ECF
committers know [6].
One of the reasons that I developed this service
based approach is that we need a common look and feel for using
different visualization tools/engines more than we need standard
graphics. I think it is important to promote this kind of
diversity because different communities want different graphics.
Having a standardized way to display 3d models in RCP would
be a great step forward. Especially as I think that a rich
client and/or server solution still offers benefits over a
webbrowser when rendering heavy load 3d models.
Other projects/companies are maybe also interested, as we
recently had a discussion with Martin Pernollet and others:
I wanted to share with you a new idea for a
visualization project that several of us have
discussed recently that would provide visualization
capabilities that meet the needs of Science,
LocationTech and IoT. I ask for your candid feedback.
Andrew and Ian, could you please forward this to
the LocationTech and IoT working groups? I would like
to get their feedback but I am not on their lists.
A few months back I started speaking to my staff about
"spinning off" some of the visualization bundles that we
have in ICE into a new project because it would make it
easier for DAWNSci to use them. Actually, I think it was
Matt Gerring's idea... At any rate, I started talking
about it more after I designed some service interfaces
and utilities over Christmas break. Since then, Jordan
Deyton has taken this further and provided a couple of
implementations of these interfaces for VisIt and
Paraview. (I only did one for CSV plotting.)
To cut a long story short, Torkild and I
immediately started talking about this idea of
spinning these viz capabilities off at the bar
on Sunday night because it might help him out.
On Monday night we had a very good discussion
about visualization capabilities at the joint
Science+LocationTech+IoT birds of a feather
meeting. Each of the groups need good
visualization capabilities and it seems that
both within and across the groups we have
technologies that we need/could share. For
example, IoT could use help visualizing
time-series data, which both Science and
LocationTech do. We had another discussion about
it over dinner on Monday night and finally at
lunch yesterday Tamar Cohen got us started on a
discussion about 3d visualization for what I
consider to be input or model generation or
"front-end" tasks as opposed to post processing.
That is, things like constructive solid geometry
and mesh editing. Part of this discussion
focused on whether or not we can replace JME3
with a JavaFX-based alternative since JME3 was
not approved through the CQ process because of
underlying contribution tracking issues with
LWJGL.
I think given the awesome discussion
surrounding this that we need to go ahead and
put together a cross-working group 3d
visualization project with initial committers
from all three working groups and an initial
contribution from ORNL and any others who have
something they want in there from the start. I
am happy to do the leg work to write the
proposal and lead the project until it is off
the ground, but in the long-term I think we need
to find a "viz person" to lead it.
I suggest that we reach out to Nebula as well
and determine how this project relates to their
existing Visualization effort, which contains
the SWT-XY-Graph bundles that most of us use. I
should mention that during our discussions we
discovered that there are some issues with those
bundles that are directly affecting several of
our projects in Science.
Let me take a minute to describe the initial
contribution that ORNL would make. We would move
two pieces from ICE into this new project
(assuming that is allowed by the Foundation).
First, we typically use third-party
visualization tools like VisIt and Paraview, so
what we have developed is essentially some OSGi
and Eclipse infrastructure for dealing with "the
plumbing" associated with connecting external
tools and native capabilities. The idea is that
given a particular visualization tool, we just
realize these interfaces and then publish it as
an OSGi declarative service. At that point, the
tools can be used to draw on SWT Composites
anywhere in the workbench instead of in a single
perspective or spot. They also publish their
preferences in the Preferences menu and Jordan
has connected everything to secure persistent
storage for handling passwords to remote
visualization clusters.
See the attached picture of a fuel pellet mesh
embedded into an Eclipse Form Editor. It was
rendered with VisIt in an external process and
piped back to ICE. Previously we could only do
this in a dedicated "Visualization Perspective."
Second, Jordan has also started developing a
JavaFX-based replacement for our JME3 geometry
builder and mesh editor. This includes, as I
understand it, extensions to the JavaFX scene
graph to provide cameras and other classes that
are similar in function to those of JME3 and not
currently available in JavaFX.
I would like to sum up this very long email
by again asking for your thoughts and comments.
I see this as a good and necessary step that
will only be successful if we work together.