On 3/25/09, Glenn Fowler <gsf at research.att.com> wrote: > > J?rg, I don't recall if you were at the 1986 Denver usenix discussions that > yielded pax, but the rancor of the tar/cpio discussions up to that point > made it clear that a single "tar" or single "cpio" only solution would > be impossible -- basically a hung jury > > since most of the disagreement was on the formats > and since there were even disagreements between some of the existsing apis > we realized that a single api would eliminate most of the problems > holding up concensus > > the pax interface was forged at a dinner atop some denver restaurant > with thunder storms circling about the whole evening (probably some kind > of daemonic omen) > > that next week I had the initial at&t research pax working for both the > proposed > standard cpio and tar formats (recall the standard initialily had both) > > unfortunately at that time it there was no opensource equivalent at at&t > and a surprisingly narrow corridor between bell labs research and the > commercial at&t unix organization -- I think the only major items to pass > that > way (after unix itself) were ksh and streams > > so the first public pax was Mark Colburn's > > I believe Colburn's implementation missed the boat > because > I believe pax should be able to crack any popular archiving format in > any of its popular forms, including compression > > the at&t pax does this by defining a plugin api (via dlls/shared libs) > and letting those plugins do most of the work > and the -x, --format=format option allows the format to be composed with > a compression method (and has room for other mthods like encryption) > e.g., --format=tar:gzip for tgz, --format=tar:bzip for tbz > and also has an extension for base + delta archives -- a very efficient > mechanism for patches and version management > > I'm sure the venn diagram of star + att pax has many interesting properties > with benefits for both implementations and the opensource community > e.g., I'm sure that star handles some format implementations missed > by att pax and vice versa -- that's no problem for att pax because > at worse it would mean just another plugin, with no change to the > main code (or possibility of interference with the already tested > formats implemented by the other plugins) > > however, at this point the issue of command line api is a dead horse > the rest can be discussed on another forum > > I won't post any more about pax here
Please ignore J?rg, he's just the resident troll at opensolaris. Discussions about pax are welcome here. Very welcome :) Jenny -- Jennifer Pioch, Uni Frankfurt
