Chris, I think you are making some rather questionable assumptions here,
not the least of which is that somebody else is going to take care of
migration. "Somebody else" means nobody.

We have a very real problem related to migrating critical community
resources from the old infrastructure to the new infrastructure. We do not
have enough resources (people, time, knowledge) to keep the old stuff
going forever, so we really do need to get on with the process of
completing the migrations. SqueakMap is one of the critical services that
needs to move.

It might or might not be a good thing to write a new and better SqueakMap
server application, but writing a new application and waiting for somebody
else to come along and do the migration does not sound very helpful.

Dave

>>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
>