[kepler-dev] how (backward-)compatible are MOML files across versions

[Christopher Brooks]

I'm on vacation, away from a working Ptolemy version, but below are
some MoML specific thoughts.

* MoML files include a version attribute 
(ptolemy.kernel.attribute.VersionAttribute?)

* 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
(https://embedded.eecs.berkeley.edu/caltrop/)
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.

-Christopher

 
 

--------

    
    Hi:
    
    I have a question, possibly mostly to the Ptolemites among the
    Keplerites:
    
    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...
    
    Bertram
    _______________________________________________
    kepler-dev mailing list
    kepler-dev at ecoinformatics.org
    http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
--------