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.

Overview/Main Points

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 rules.
"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.

Relevance

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.

Flaws

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