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:
- The problem of finding, downloading, and installing Squeak packages as well as the problem of publishing packages so that everyone else can find it.
- The problem of mapping a developer initial to a real person with a name, email and that developer's packages.
- The problem of mapping a PackageInfo (the current means for package definition) name to a SqueakMap package.
- The problem of categorizing packages etc in categories.
- The problem of recording the history of package installations in the image (version, time etc).
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:
- 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).
- Look into Universes from Lex and try to merge/integrate that functionality with SM.
- 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
Commentary
Back to New Modules
