Hi!

John Pierce <john.raymond.pierce at gmail.com> wrote:
> On Tue, 12 Oct 2004 18:26:47 -0300, Hernan Tylim <htylim at yahoo.com.ar> wrote:
> > Hi Goran,
> > 
> >         The problem with using the SM Cache for this "image building scripts"
> > is that you need to keep a unique sm/ folder for all your images, which
> > is not always desirable or even possible (think in a PC at home, and a
> > PC at work for example).
> 
> First of all, the sm cache is not much use in my targeted application
> of the SqueakInstaller.  In the usual case I am using SqueakInstaller
> on *brand new* images.  So if you cache it or not, my sm is *always*
> squeaky clean (no pun intended) and not much use.

Eh, no - it is still used in fact. :) SM looks in the "sm" directory in
the default directory, so if you have placed your brand new image in the
same directory as your other images they *all share the same cache*.
They even share the same map, so it isn't needlessly downloaded for each
image.

If you *don't* have an "sm" directory there - then sure, the cache isn't
there.

> >         What I like of the SAR approach is that it is very self-sufficient. You
> > just bundle everything you need in the sar and you execute it in any
> > image you want.
> 
> Second of all, I think the SAR approach interests me in certain
> applications, but I think caching (either in SARs or in the SM cache)
> is purely an optimization and I am less focused on optimizations at
> the present moment.
> 
> One motivation to cache is to improve performance.  I am not so
> worried about the 5 minutes it takes me to setup my new image as it
> stands now.  That is much more performant than doing it by hand.  The
> other reason to cache is to have redundancy of packages.
> 
> Frankly, I think it would benefit the community at large to have more
> redundant SM servers and SqueakSource servers (and anywhere else we
> decide to squirrel away our code).

SM will both get a server side cache (making it much more resilient to
outages of the package hosts) and a mirroring scheme so that we can set
up master mirrors on the net.

Then, further into the future SM will move into a more distributed
multi-server model.

> So I am not saying I am not interested in caching on the client, but I
> think the utility is marginal for my targeted application.  Plus,
> there is a real downside to caching that hasn't been mentioned!  Stale
> caches!

Since SM caches package *releases* (not just the "latest version") they
don't get stale, unless the package maintainer modifies a release *in
place* which is BAD BEHAVIOR.

>  I happen to like the ability of SqueakInstaller to grab the
> latest versions of MCZ packages and install them.  I don't always want
> to work it that way, but sometimes I really do -- and caching in SM or
> SARs gets in my way in these cases.
> 
> Now, if I could setup some sort of SM caching server and/or
> SqueakSource caching server in my organization, that would be quite
> handy, but certainly outside the scope of SqueakInstaller.

Planned for future, for SM that is.

> Regards,
> 
> John


regards, Göran