>SqueakMap uses Monticello to load packages, so that is not a problem. It
>also allows other loaders to be used, which may be important for older
>packages.

Yea, the changes I'm making to a new version of SqueakMap will heavily favour this. The idea is that SqueakMap is not a repository (no saving code on box4) and code should be in a SqueakSource repository somewhere. At bottom, the map is a file that stores URLs. So if you want to store an alternate file format (i.e. sar), then you could put the file on a server of your own. Then you'd put the URL into the map as the release. But I think that the days of storing code on a Squeak box, which is then served by SqueakMap will not be continued in the migration to box4. 

That, of course, raises questions. What to do with all those (85% empty) directories in /squeakmap/sm/cache and /squeakmap/sm/accounts? 15% of those contain code of some sort. My attitude is that I may be working on a new version of SqueakMap server, but that I'm not responsible for migration. The new map will be an empty file. It'll only have the apps that I've put into it. Empty. 

I figure let people migrate if they want. If not, zip the whole thing and store it somewhere. 

>The only problem I have with SqueakMap is that for packages like
>TwosComplement or PunchedCards on SqueakMap, which run on more or less
>any version of Squeak, I am expected to remember to update those packages
>on SqueakMap every time someone releases a new Squeak version. This is
>annoying and eventually I might run out of patience and forget to do it.

This is interesting. This speaks to me about a catch-22 involving categories in SqueakMap, which is one of my least favourite features. I think your old code is always available, but the labels make it invisible. I think Chris Muller uses the filters (based on categories) liberally with each release. The reasoning is sound: only show packages that have been labelled as working with the latest release. The reason for that is to keep the hundreds of rotten packages out of sight. That's an admission that all those old packages are a problem. The catch-22 comes in, I think, when I say the new SqueakMap will be an empty file, a new map, and that all those old packages should ether be thrown away, or, at best, zipped into a glob and stored into a closet. I imagine this idea will meet with some resistance. 

The thing you need to know about the new SqueakMap is this: I'm building the tool I want to use. The Squeak community may be responsible for a legacy of SqueakMap code, but I, Chris Cunnington, am not. I will have moved things forward. If it's not far enough for people, the source will be freely available. It will be one of the first packages in the new map file, the 7000 series, (as opposed to the 5000 series). You'll be able to download the SMServer code from SqueakMap. 

Chris 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140409/9f754fe9/attachment.htm