another m2m example
- Most OS package-management systems have GUIs these days, and the back-
ends to these systems mostly use wget (mostly to FTP sites) as user
agent. What URIs to have wget fetch, are determined by the text
configuration files (patches, prerequisite packages, options etc.).
If a URI is unavailable, an alternate is selected and processing
continues -- the user selecting these application state transitions
expressed as URIs, is the installer process (i.e. ports/pkgsrc), no
human involved except to select options and initiate the installer (via
hypertext API of course).
The media type of each patch tells us the encoding of its tarball, not
that when extracted it's part of a numbered set of patches for some
other tarball. This processing model may be standards-worthy -- as a
multipart media type which allows each tarball to be a set of alternate
links in order of preference (or via net heuristic), and establishes
the order in which the patches are to be applied.
Just a thought -- while a RESTful-m2m fork of pkgsrc would be fun, I
hardly have the time. Instead of downloading a tree of stub files, the
installer dereferences the package manifest of the requested package
from some host, the representation is this new multipart media type,
which defines the sender's intended processing model -- guiding the
installer's use of wget as its agent, extracting and patching together
the returned tarballs.