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@gmail.com wrote:
On 2012-10-27 1:25 PM, Chris Muller wrote:
On SqueakMap, FWIW, I'd recommend these changes:
- 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).
- 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.
- Encourage people to load scripts into the "Create New Release" GUI
app, so applications, not packages, are installed with a single click.
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