View this PageEdit this PageLock this PageLinks to this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide

SqueakMap 2


Other pages:

Development of SM2

  1. Grab the latest 3.6. 3.6 is the intended base for SM2.
  2. Remove category "SM-domain". Destroy changeset "New Changes" (to get rid of it)
  3. Upgrade all installed packages.
  4. Install from SM: MCInstaller, Monticello, VersionNumber, Kom6.2, HttpView2
  5. Install using Monticello browser from the latest of SMBase, SMServer
  6. Make sure you have an "sm" dir with a 1.0x log file (should have after the above), do: SMSqueakMap clear; default reloadLog
  7. Add developer initials from minnow: SMSqueakMap default migrate
  8. Start the web UI: (SMRootView map: SMSqueakMap default) startDebug
  9. Stop it: SMRootView stop
  10. Surf in at http://localhost/sm

Various doits:

"Set up your password manually"
(SMSqueakMap default accountForEmail: '') setNewPassword: 'buff'

"Change admin pass to be able to manage categories"
SMSqueakMap default adminPassword: 'sesame'

Similar solutions to SqueakMap

What we need in SM2

The current SM works fine but it has quite a few shortcomings.


The current SqueakMap only keeps track of the latest release and a download url for it. But we need to keep track of old releases too - otherwise we will never be able to handle dependencies correctly.

SM1.1 will add PackageReleases. This means that when you register a Package you can then - as children objects to the Package - register PackageReleases. They will be autonumbered as well as have a designated version name (as currently on SM).

A proper package cache

Current SM doesn't have a cache. It just downloads into a directory and overwrites any previous downloaded file with the same name. Since it has no concept of releases it can hardly be much smarter.

SM1.1 will have a proper cache with the following structure:

{Package UUID}
{Package release autonumber}

SM keeps all its stuff under the directory "sm". There will be a new subdir called "packagecache".
In this directory you can see each package has a directory of its own. In that directory we will have one directory for each release. And in that directory the downloaded file is kept along with anything else we would like to have.

This cache will be used as a real cache so SM1.1 will always first check the cache. This means that we can distribute a partial or full cache in the Squeak zipfile or on a Squeak CD.

The same structure will be used on the master SM server which will maintain a cache of all registered packages. This removes the spurious problems we have been having with people publishing stuff and then accidentally invalidating the URL or perhaps simply dropping of the net somehow.

So clients will be able to fetch a package release from either its original URL, or if that fails from the master SM server cache.

This also means that we can easily set up rsync mirroring of the master cache if people are interested in maintaining full mirrors of the master cache.


In SM1.1 packages have releases. But sometimes you want to refer to something that is not package. A resource of some kind that can be associated with packages or package releases.

A Resource will work approximately like the packages do today on SM. There will only be a link to the latest version of the resource. The idea is to enable other systems to "piggy back" on SM by being able to attache state (Resource) to packages or package releases. Almost like an attachment.


This is simply a Resource that is kept inside SM instead of as file accessible by a URL. This means that MapResources need to be somewhat small. They are simply kept as a String.

MapResources are thus also an enabler for other systems to "piggy back" on SM. But these resources are always available inside the map - no download needed.

The main intended first use of MapResource is for managing dependency information for PackageReleases. But this is not included in SM1.1 - it is simply what we need in order to implement dependency management on top of SM - simply a place to put the additional information.


Links are just the way Resources, MapResources, Packages and PackageReleases can refer to each other. Any so called SMObject (the baseclass for the mentioned objects) can have links to others.

And the Links are also categorizable which means that we can classify the links. This gives us a chance to associate a Test package with the package it tests and so on so that tools can find them.

Odds and ends