wpk: A Packaging Idea

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:


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

   web-package-opener %s


   web-package-opener foo.war


   web-package-opener /tmp/3l4kj53lk.war

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.


Afterthought: Union Links

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.

See Also

Dan Connolly
$Revision: 1.3 $ of $Date: 2000/10/06 05:06:49 $ by $Author: connolly $