A domain in Ptolemy II implements a model of computation, which effectively
defines the interaction between a collection of actors. It does so be controlling
the exchange of tokens among actors as well as their scheduling, i.e. it determines
when each actors fires. In order to do their job, domains often employ special
"contracts" in addition to the generic Ptolemy II actor/director/receiver
contracts. These may range from special attributes (such as the token rates
for SDF actors) describing specific actor properties of interest to the domain
to the use of sophisticated specialized infrastructure (such as the one used
for reading and writing tokens in CSP).
Actors that are to be used in such a domain therefore need to (a) be aware
of its existence and (b) need to be coded to its particular assumption. This
tends to tie in actors to a specific domain, and also introduces dependencies
between domain code and actor code, contributing to the brittleness of the
Domain-dependent interpretation of CAL actors tries to address these issues.
The basic idea is that there is a variety of domain-specific CAL interpreters,
which interpret the same CAL description slightly differently, making use
of domain-specific interaction mechanisms, while keeping the CAL description
itself agnostic about the domain or the way it is implemented. This provides
the following benefits:
- Actor descriptions become more domain-polymorphic, and thus reusable,
while still making use of domain-specific mechanisms and features.
- Actor descriptions are decoupled from domain implementations---changes
in the way domains are implemented do not affect actors, once the domain-dependent
interpreter has been updated.
- Actor writers do not need any specific knowledge about the implementation
of domains. All they need to know is how actor features are interpreted
in the context of a domain.
A domain-dependent interpreter (DDI) has to perform the following tasks:
- When given an actor, it has to determine whether that actor is well-formed,
i.e. whether the actor can be legally used inside the domain. The well-formedness
of an actor might depend on the context it is used in, in particular it
might depend on the values given to its parameters, but also, in principle,
on the way it is related to other actors in the same model.
- For any well-formed actor, the DDI publishes the static properties
that are relevant to the domain in a way that they can be seen and used
by the director. This usually involves analyzing the actor and annotating
it with attributes that are understood by the director and that reflect
the analysis results.
- For any well-formed actor, the DDI produces the dynamic behavior
of the actor by interacting with the domain according to the generic Actor/Director
API as well as any relevant domain-specific constructions.
The current implementation inside Ptolemy uses a generic typed atomic actor
It detects the model of computation it is running inside of and then instantiates
a domain-dependent plugin that contains the DDI. This architecture allows
CAL actors inside a model to adapt when the designer changes the domain of
the model without further user intervention.