real-time constrains for tunes migration

[Brian T Rice]

On Sun, 28 Dec 2003, Mark Baily wrote:

> One of the problems involved in real-time operations such as music or
> graphics is specification of those operations which have constraints in
> terms of how long operations are allowed to take. In distributed
> programming the encoding of any communications (serialization) may be
> done on a continuum of flexbility vs speed. As is typically done,
> hand-crafting purpose-built protocol examples are "Open Sound Control",
> "MIDI", "Chromium" (for streaming opengl primitives) or CORBA real-time.
>
> But hand-crafting such protocols results in a lack of a continuum for
> real-time operations, meaning lack of expressivity for specifiying
> small, medium and large time values and in between, for operations, let
> alone programatically determining these time values.
>
> Instead, encodings/protocols can be automatically generated by a
> program, based on a specification of speed required for each
> communication.  How does this fit in with the Tunes migration project.

It's a resource allocation strategy or strategy-generator. Coupled with a
system that can apply staged partial evaluation, it doesn't have to affect
the runtime requirements, as you note. So this is under the domain of
migration, but of course it's also static and low-level. The actual
allocation/scheduling abstractions and strategy generators would be part
of the migration aspects, and the low-level choices and basis data /
protocols would be part of the low-level aspects of the system.

There is a paper about rewriting logic (with meta-level) as a general
high-level formalism suitable for expressing resource-allocation and
scheduling. The paper I am thinking of is somewhat associated with the
Maude project, as I recall, and is applied to memory-management domains,
but there is also a paper about using meta-strategies to work with
real-time constraints in Maude.

PS: My focus right now is on Slate and on deriving some funding, so I
cannot provide extensive support lately for other TUNES activities without
assistance.

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/