[kepler-dev] how (backward-)compatible are MOML files across versions
cxh at eecs.berkeley.edu
Thu Aug 19 20:27:39 PDT 2004
I'm on vacation, away from a working Ptolemy version, but below are
some MoML specific thoughts.
* MoML files include a version attribute
* I think there is some sort of annotation that one can add to a model
to require a particular version or later of the Ptolemy runtime.
* We spend a certain amount of effort on backward compatibility.
ptolemy.moml.filter defines filters that change port names, class
names, parameters etc. This approach is not perfect, but it get us
part way there.
Relying on the Ptolemy version number is rather coarse grained, and
since Kepler and Ptolemy will not have the same version numbers, this
will not work real well for Kepler. We could introduce a separate
version parameter for Kepler, or expose the setting of the version
value so that Kepler could change it in a configuration file.
One way to handle versioning is to have actors have version numbers
and have the model require specific versions of the actors. Usually,
one increments a major version number for incompatible changes and a
minor number for compatible changes. For example, an actor could
require version 1.2 or later, and we could use CVS version numbers.
(There are lots of ways to do this, the preceding is just a guess.)
Looking at how Solaris/Linux shared libraries, Windows dll files, Java
jar files and Linux RPMs handle versioning might be of interest.
There is a certain amount of crossover with how Web Start handles
jar file versioning.
I think that in general packaging up software in a modular fashion
with dependency management is an interesting area of research.
In looking over your message below, are you are proposing
a meta language that describes what services are available?
I guess my only thought there is that it would be nice if
it was very human readable, with Java-like syntax, or
else XML, which would look like MoML, but be different(?)
BTW - Caltrop is a language to define actors
but I sure don't care for the syntax much. Why invent
yet another language :-)
Anyway, the above are some random thoughts, take
them with a grain of salt.
I have a question, possibly mostly to the Ptolemites among the
If I create a workflow/model and save it as a MOML file and it runs on
my Kepler version as of today, how can I know whether this file works
with a previous Kepler release or with a future one.
I noticed that MOML files are not "self-contained" and refer to Java
classes etc. If one views MOML as the Kepler/Ptolemy "internal"
language (working with a particular Kepler/Ptolemy build), then what
does an "exchange" language look like.
For example, if I have a web-services only based workflow, then it
should run back and forth the Kepler release history (as long as the
web services defined in it remain valid).
So overall what I think we need is a more self-contained an explict
format to "archive" workflows. Among the things to be added would be
"imports" or "uses" statements in the header so that dependencies on
external tools and services would become explict.
Thinking a bit further, in the web services setting at least, but
maybe beyond, one would could think of a "binding mechanism" so that a
workflow mentions a remote service S of a particular type, say
S :: highway_number --> traffic_info
(S returns current traffic info, given a highway number)
but the actual WSDL or location of the service is a parameter that is
only bound later...
kepler-dev mailing list
kepler-dev at ecoinformatics.org
More information about the Kepler-dev