links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Summary: Packages on SqueakMap
Last updated at 3:03 am UTC on 1 March 2005
Reported by Göran Krampe

What problem is being addressed

The general problem of sharing information - the need for a shared domain model of things we want to have cataloged (mainly packages, but also developers etc).
More specifically today SqueakMap addresses:

How it solves the problem

SqueakMap is mainly a catalog system, but I want it to further evolve into a general "shared memory" of the Squeak community thus cataloging much more things than today.
Today it catalogs "accounts" (developers) and "packages" (in a wide variety of formats) and also includes code to install those formats, typically using other packages like MCInstaller, Monticello, SAR etc. It also has a category tree for classification of cataloged things.

The architecture is still KISS - a central server with a web UI to maintain the model, and the clients can either use the web UI or more importantly the SqueakMap Package Loader. A Squeak image with SqueakMap has a local copy of the domain model in the image (and checkpointed on disk as a compressed ImageSegment, which also is the transfer mechanism from the master) and then a UI on that model - the SqueakMap Package Loader. You can either use the catalog domain model directly (doits or whatever) or use the tool. Since SM uses an ImageSegment the domain model is very "free" to evolve - no restrictions/extra burden for persistency.

The things SqueakMap needs immediately are better caching (server side, not just client side which it already has), better error handling (detecting failed URLs), a trillion other small improvements, some nice enduser features (preloading cache etc) and last but definitely not least dependency management for packages.
Most of that is already in my development image, including a working dependency model - which needs a bit more code, but it works.

What I want to do (unless other things change that) is to:
  1. Make a new release of SM with the stuff I have (server cache, fixes, alpha dependency model) still using the current simple architecture (ImageSegments, single master etc).
  2. Look into Universes from Lex and try to merge/integrate that functionality with SM.
  3. Move SM to a distributed architecture opening up possibilities of local or company/institutinal wide semi-private information etc. It would also mean moving away from a single master and that would make the tools able to also modify the map, not just use it readonly (as today).

Regarding dependencies, today Monticello has a "classic" dependency scheme built in. But Monticello is a SCM system, not a package system like SM is - so the needs are different. The model in SM is quite different and very promising on paper IMHO. I intend to write an article about it very soon (during 3.9), but several postings have been made over time describing it in detail.

Useful links

http://anakin.bluefish.se/gohu/11, more links there - to a few articles on SqP that are quite good. :)

For coherence I think the author should write the sections above this line.
People can add what they want to these later sections, and can suggest that the author change the rest.

What's cool about it

What's not


Back to New Modules