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