> Of course, there is little chance that typical fast machines would be
> discommoded by using zipped images, and PDAs would benefit quite a bit,

I have two small comments on the PDA side: 1) power consumption 2) memory
usage.

1) Power Cosumption
One has to way the advantages and disadvantage of each PDA platform.  The
more CPU one uses the more power is used as well, this means that battery
time is reduced.  This can be a serious issue.  I'm using a few different
platforms at work and find that different ones have different battery usage
styles.  My iPaq cannot last more than 2 weeks while it is OFF and sitting
there on my deks, without being plugged into its power supply.  While I have
a Palm IIIx that was sitting in a box since I moved, 3 months ago.  I pulled
it out a couple of days ago to do some testing, and the battery meter still
read 75% battery life left.  So my point here may be lost, as it seems that
machines like the iPaq assume that its plugged in as much as possible :)
But the point still remains, power consumption can be a problem if you are
not careful.

2) Memory Consumption
In Palm OS, even though Squeak is not running there (yet :), it is still a
PDA platform and most of the problems to get Squeak running there will go
away when they switch to ARM.  Using compression to store the images would
not give you a lot.  There is no "load" necessary in the case of Palm.
Simply open the "file" (database in Palm lingo) and use it directly as a
memory mapped chunk.  So having a compressed form would increase the memory
requirements, the zipped form PLUS the expanded form would need to be kepts.

Saving an image is also not as necessary here, since all you would do is
close the "file", as all (most anyways) writes would be done to the "file".
This is the strategy that Pocket Smalltalk uses today.  IF one did use
compression, then this would also increase the amount of time needed to exit
an application, which is not a good thing for Palm based applications.

Two cases here which I think is worth mentioning, where compression would be
interesting: keeping a virgin application image and using applications
stored on external media.  An issue of saving the image, is that if the code
has bugs in it or memory leaks, then saving the image keeps all artifacts
around, good and bad.  So if the image gets itself into a state where it can
no longer run, the VM vould simply replace the latest image with the virgin
one.  Keeping the virgin one zipper would be good in this case, as it
minimizes storage requirements for something that will hopefully be never
used.  This is something being considered for PST.

External media on some of the Palm expansion, and others as well, has a VERY
slow interface to retrieve data.  The current way things work on these types
of slow data expansion slots is to move the application from the media and
into RAM.  Palm devices will be doing this in the forseeable future.  Here I
think compression could provide some useful results.

The iPaq has somewhat the same capabilities.  I don't know how the WinCE
edition of Squeak works, but one does not have to "load" an image into RAM
and then run, the image is already in RAM.  You could run directly from the
image "file".  So memory requirements go up.  For our iPaq work, we use the
same strategy as on Palm.  We have a "perm space", which is where code lives
and is accessed by opening the "file" and accessing it directly.  All
dynamic object creation occurs in dynamic RAM.

PS: Sorry about the grammar errors, I started realizing half way through
that my small point was expanding.  Hopefully the points I am making can be
understood by this blurbage.