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:

   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

   application/web-package

your buddy's MUA, when asked to open it, finds a MIME type config entry that tells it to invoke

   web-package-opener %s

i.e.

   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.

wrinkles:

for creating packages, just list URIs on the command line or on stdin
perhaps a package should have a nominated starting place, i.e. the README/index.html or whatever
before bundling the stuff up in zip format, it should be suitable for burning onto a CD-ROM or whatever, ala the verity thingy (@@ref) or the Hal web proxy(@@ref)

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.

wpk: A Packaging Idea

wrinkles:

Afterthought: Union Links

See Also