SqueakMap ( was Re: [squeak-dev] Crypto package loading?)

Chris Cunnington smalltalktelevision at gmail.com
Sun Oct 28 18:39:38 UTC 2012

On 2012-10-27 1:25 PM, Chris Muller wrote:
>> On SqueakMap, FWIW, I'd recommend these changes:
>> 1. When it moves to the new server, discontinue the web access. Make it GUI
>> access only. Updating the SqueakMap server as seen at map.squeak.org is
>> endless, tedious, and superfluous.
> We still need the web interface to do other things like creating new
> Packages and maintaining Categories, among a few more use-cases.  We
> cannot get rid of it yet, but the server is some of the most difficult
> code to maintain -- so I'd be all for the notion of a complete
> replacement using Altitude or any other web-framework.  Someone was
> working on that at one point (Green-Neon).  ;)  Given Squeak's web
> capability, it seems like it would not be that hard given that the SM
> domain model is small and fairly simple (and could even stand to be
> simplified a bit more).
>> 3. Remove "SqueakMap Categories" from the "open..." menu because it's
>> redundant.
> +1
>> Replace it with "Create SqueakMap Release" so it's easy to find
>> Chris M.'s GUI app.
> I think creating a Release is an operation that can only happen in the
> context of a selected Package, so it may not be a simple matter to put
> that on the open... menu.
>> 4. Encourage people to load scripts into the "Create New Release" GUI app,
>> so applications, not packages, are installed with a single click.
>> http://wiki.squeak.org:8080/squeak/6182
> Yes, and to Frank's concern about HA, recall that SM has always worked
> by downloading a copy of its domain model to the local machine.
> There is no doubt that SqueakMap domain, server and UI need to be
> simplified and/or replaced, but until someone can step up to do it,
> what we have now at least works for a crude App Store.
> Thanks.
I think there needs to be a server for SqueakMap, but I don't think that 
server should have a public interface.

SqueakMap shouldn't have releases, only a single Installer script per 
application. The package and release distinctions need to be put aside. 
There shouldn't be one package with lots of releases. If people want to 
explore releases or versions, they can go to SqS or SqS3. Part of the 
confusion is that package names are also the names of the applications. 
SqueakMap should be about applications, not packages or releases. And 
for each application, there should be only one Installer script. There 
should be no categories publicly changeable by users. Only 
administrators. You have a GUI for downloading something from SqueakMap 
and a GUI, a reworked version of Chris M.'s new release GUI, to add an 
application to the map or to change an existing Installer script. SM 
should list, add and execute Installer scripts.

That's it. The taxonomy and nomenclature here needs to change from 
category, package, and release to application and script. SM today does 
too many things.  A new SM should do one thing - download applications. 
If people want to move beyond that simplicity, then can read the 
installer script readily visible and pursue the constituent packages 
spread into releases available at a public repository like SqS or SqS3.


More information about the Squeak-dev mailing list