[plt-scheme] Unix install

On Wed, May 03, 2006 at 10:29:15PM +0000, Matthew Flatt wrote:
> Here's a suggestion:
> 
>  * Ask us about the requirements that we know
> 
>  * Add the requirements that you know and we don't
> 
>  * Design a format and build tools that work better.
> 
> Then we'll all be happier.

Well, one requirement that I'm interested in is whether it's really
necessary for an archive to be able to contain arbitrary code for
handling queries and installation. The price of such flexibility is that
static analysis of archives stumbles on Rice's Theorem...

But anyway, if you want concrete suggestions, the jar/xpi approach seems
best to me: use zip as the archive format, and store metadata in some
specially named files within the archive. For direct duplication of the
current .plt organization, there might be two files named e.g.
"pkg-info.ss" and "install.ss". Admittedly zip is not the prettiest
format on earth, but it's probably the most ubiquitous and best
supported. More so than tar or StuffIt, anyway.

I really think that ASCII armoring should only be done as a separate
step that is not tied tightly with the actual archive format, but if
files are still to be distributed as base64, the data just needs some
sort of a header. Unfortunately base64-coding of static files is so rare
that it hasn't been standardized very well. I suggest using either the
uuencode way:


begin-base64 644 foo.zip
UEsDBBQAAAAIACUPpDSMLcD6DwAAAA8AAAAHAAAAZm9vLnR4dAvJyCxWAKJE
hZLU4hIuAFBLAQIAABQAAAAIACUPpDSMLcD6DwAAAA8AAAAHAAAAAAAAAAEA
AAAAAAAAAABmb28udHh0UEsFBgAAAAABAAEANQAAADQAAAAAAA==
====


Or making the file an actual MIME document:


MIME-Version: 1.0
Content-Type: application/zip; name="foo.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIACUPpDSMLcD6DwAAAA8AAAAHAAAAZm9vLnR4dAvJyCxWAKJEhZLU4hIuAFBL
AQIAABQAAAAIACUPpDSMLcD6DwAAAA8AAAAHAAAAAAAAAAEAAAAAAAAAAABmb28udHh0UEsF
BgAAAAABAAEANQAAADQAAAAAAA==


The latter approach is more extensible, although use of MIME in plain
files is rather unorthodox.

The implementation difficulty depends on requirements. There's lots of
free software for manipulating zip files, and of course the simplest way
would be to just call "zip" and "unzip" when needed (possibly
distributing versions of those to ensure that they are available
everywhere). Tighter integration with scheme code (scheme bindings for C
libraries, or a new, purely Scheme-based zip library) would be a bit
more work.


Lauri