Back to index
Towards a Design Methodology for Adaptive Applications
Malcolm McIlhagga, Ann Light, Ian Wakeman
One-line summary: For media proxies that adapt by distillation, apply
perceptual and UI research to determine how to present the interfaces for controlling the
service, and a configuration-file-like language for expressing policy for degradation.
- Media policy language (mpl) example:
media.image.* : true : toMono If media type is "image" of any
kind, convert to monochrome.
media.image.jpeg: meta(progressive) == false: toProgressive If media is
image/jpeg and not progressive, encode as progressive (procedure call)
- Policy scripts in mpl can be attached to pages, objects, or set by users or proxies.
They are compiled together (logically anyway) to come up with a complete policy;
various precedence rules determine what to do when (e.g.) users and authors have different
- "Environment" variables (image dimensions, image metadata, client parameters,
etc.) are made available to policy scripts, simliar to CGI.
- Nice side effect of paper: Perceptual experiments to determine
JPG quality level at which degradation is noticeably bothersome to users, for a small set
of different types of JPG images.
Interesting potential concept here is "hint style sheets" separate from pages
themselves, as in CSS or WIDL. Mpl examples suggests that a purely declarative
language may not be appropriate; a simple scripted language (embedded Tcl?) may be better,
though harder to provide a "novice" forms interface for customization.
- Proposed implementation of doing multiple rule firing on every request may be overkill.
- Media type hierarchy needs to be extensible (like MIME); this introduces issues for the
scripting language, which knows about different metadata, environment info, etc. for each
media type/subtype. E.g. what if you ask for the 'progressive' property of a BMP
because all you know is that it's an image/*? This is the classic problem of
describing a hierarchy and attributes for an extensible set of types, which is why an
interpreted scripting language is probably the right choice (late binding of attributes
allows "default" values to be returned, etc.)
Back to index