packager: proxy server:
% web-package-maker --output foo.wzp --work-dir work accepting connections at http://localhost:9549 visit http://localhost:9549/admin to stop, get help, configure, etc.
then you tell your browser to proxy HTTP (among others) to http://localhost:9549
it keeps copies of everything you GET in the work dir, along with all the request and response metadata.
then you visit http://localhost:9549/admin and hit the stop button, and it writes out a zip archive in foo.wzp ala:
manifest.rdf pathbase1/ pathbase1/index.html pathbase1/stuff.html pathbase1/images/ pathbase1/images/img1.gif pathbase1/images/img2.gif pathbase2/index.html pathbase3/foo.gif
where each set of URIs that match up to a zip-filename-compatible tail go in one pathbase
so stuff coming back from ?big=query&uris=andSuch will each go in a separate pathbase, but other stuff will have a chance of relative URIs working in file: mode.
(hmm... is this pathbase stuff worth bothering with? do we ever expect folks to access these via file: URIs?)
ok... then you attach foo.wzp to your mail message, and mail it to your buddy, labelled as
your buddy's MUA, when asked to open it, finds a MIME type config entry that tells it to invoke
or whatever. This starts another proxy server:
accepting connections at http://localhost:4654 visit http://localhost:4654/admin to stop, get package contents, help, etc.
You friend tells his browser to use that as an HTTP proxy, and then visits any of the URIs in the package, perhaps starting at the admin page to find the contents.
As long as we're doing packaging, my intuition says they should have union links, ala propero and plan9 (@@link)
Anybody who's doing an "virtual filesystem" that groks HTTP, FTP etc. should also do union links.
Why, you ask? Hmm... I can't think of an explanation just now, but it seemed important a little while ago.