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.

See:

   http://wiki.squeak.org/squeak/6182
   http://wiki.squeak.org/squeak/6183




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
>