SqueakMap updating fails to update files

http://download.scratch.mit.edu/source-code/ScratchSkin1.4.zip\.

There’s not much wrong with this link. Click it. Then remove the trailing slash. It downloads. 
How about posting that Installer script here. I’d like to see it. Because that’s all we’re talking about: saving an Installer script to disk for future download. SqueakMap server makes that process staggeringly unreliable and complicated. 
It would be easiest to just store them in a directory accessed by the Squeak FTP client to download them. That doesn’t have the helpful meta-information and labeling. But that’s exactly the same thing. (I fixed that FTP problem ages ago. I think I put something in the Inbox. I don’t remember clearly.)
All we’re talking about here is Installer scripts. SqueakMap may have once had an all embracing, extensible design, but the use case has been reduced to this one alone. Installer scripts won. 
This kind of thing could be knocked together pretty easily with Seaside: uploading files to download later. And really, since SqueakMap model is in every image, it would be easy to subclass and extend those classes, so that the ReferenceStream was a catalogue of Installer scripts explorable through the SqueakMap UI instead of that categories and package info gibberish. Who wouldn’t want to down a file that allowed them to explore 100 Installer scripts using the SqueakMap UI? 
I would imagine all that stops such a sane course is archiving a catalogue of legacy projects which can no longer be loaded into contemporary images. 
Chris 

Nina Haaaaaaaagen
https://www.youtube.com/watch?v=JWzPcDtZZZo

> It would be easiest to just store them in a directory accessed by the Squeak FTP client to download them. That doesn’t have the helpful meta-information and labeling. But that’s exactly the same thing. (I fixed that FTP problem ages ago. I think I put something in the Inbox. I don’t remember clearly.)
>
> All we’re talking about here is Installer scripts. SqueakMap may have once had an all embracing, extensible design, but the use case has been reduced to this one alone. Installer scripts won.

SqueakMap still has everything it always did,
including support for apps with resources (via .SAR files).  It's just
that the most-common case are applications that are code only but
require more than one single .mcz file for configuration.  Installer
scripts provide the most convenient way to have compatibility with all
the various code repositories and formats.  I like its transparency,
too..

> This kind of thing could be knocked together pretty easily with Seaside: uploading files to download later. And really, since SqueakMap model is in every image, it would be easy to subclass and extend those classes, so that the ReferenceStream was a catalogue of Installer scripts explorable through the SqueakMap UI instead of that categories and package info gibberish. Who wouldn’t want to down a file that allowed them to explore 100 Installer scripts using the SqueakMap UI?

I plan to replace the SqueakMap server infrastructure with a GraphQL
API service that could be accessed by either a Seaside webb server or
a Squeak client.  I plan for it to be the maiden test application for
the new GraphQL framwork I hope to finish soon.

> I would imagine all that stops such a sane course is archiving a catalogue of legacy projects which can no longer be loaded into contemporary images.

Let's revamp the server that hosts and and client-infrastructure that
presents it before talking about revamping the model.  A lot of
usability improvements are possible and planned without needing to
make breaking changes to the domain model.





 - Chris