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

Chris Muller asqueaker at gmail.com
Sun Oct 28 22:18:42 UTC 2012

Chris, that completely ignores what got SqueakMap into trouble in the
first place.  The primary requirements are:

  1) A trunk-like process for each application.  Install or Update the
"head" release of an application.
  2) Install an EXACT configuration of an application that is *known
to work* with a exact version of Squeak.  This is needed to protect
the works themselves from bit-rot, so they can be brought forward more
easily.  Not everyone is operating off the trunk.
  3) Quality over quantity.  If an application is in the list, *it
must work*.  That's why, with each new Squeak release, the list of
loadable applications is blank until authors manually tag a Release to
work with that new version of Squeak.

While I'm all for some simplifications, Releases and Categories are
are absolutely essential to the model.



On Sun, Oct 28, 2012 at 1:39 PM, Chris Cunnington
<smalltalktelevision at gmail.com> wrote:
> 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.
> Chris

More information about the Squeak-dev mailing list