SM2 has landed!

Posted 19 Jan 2004 by gokr (Master)

Yesterday SM2 - version 2 of SqueakMap - was deployed and things went reasonably well. Now inevitably one may ask, what's all the hoopla? :-)

So... how does SM2 differ from SM1? That is indeed a good question.

Let us start with the model. First of all SM2 introduces two new objects - the SMAccount and the SMPackageRelease. SMAccount is the object representing the package maintainer. In SM1 we only had a textfield with an email address to indicate who was the maintainer. We also had the concept of registrant - the person registering the package on SM - but we have dropped that in SM2.

SMAccount gives us a place in SqueakMap where we can hook in data about the package maintainer. Butyou don't really need to be a maintainer to get an account in SqueakMap - so we can actually have accounts for all Squeakers that would like to be listed as Squeak developers. As our tools evolve this canonical list of Squeakers will probably become more and more important.

Today SMAccount keeps track of:

It also has a boolean saying if this account has admin privileges - something only I have at this point, but I think a few others will join me later on. :)

One nice thing SMAccount gives us is better navigation - this can be seen in the web frontend where you can easily see which packages a certain account owns etc. Another important thing is that we can now easily get the name and email given a pair of developer initials, and we can also get all of this given a SqueakMap package.

When SM2 was deployed it ran some code to try to match the emails of maintainers from SM1 with the developer initials currently listed on the Squeak Swiki. It did a pretty good job - those of you it missed will have to set it yourself under "Settings". Anyway, we should IMHO now consider if SM shouldn't be the canonical true master copy of the developer initials. :)

Ok, let us move on to SMPackage. This class was named SMCard in SM1 but I renamed it. SMPackage now has instances of SMPackageRelease as children - this is one of the most important new things in SM2 - the map keeps track of older releases - not just the latest.

SMPackageRelease instead of SMPackage now carries the version field, but an extra field was also added holding an instance of VersionNumber. This is the automatic version which the maintainer can not affect. Without branches (which SM2 doesn't support yet) it simply goes "1", "2", "3" etc. This version number convention gives us a common reference when needed.

SMPackageRelease also keeps track if it has been "published". This is a second stage of commitment from the maintainer. The idea is that an unpublished package release can not really be trusted. It may get deleted by the maintainer tomorrow. :) But a published package release does indicate that the maintainer will not delete it - but it isn't enforced by SM. A release also keeps track of who published it - an important aspect when there are co-maintainers involved. Currently this extra information is not used in the package loader - but a typical filter would be to only show published releases. Typically it is the published releases that you can depend on.

Back to SMPackage. SMPackage also has an RSS field (Brent requested it, hey why not) and more importantly a PackageInfo name field.

That last thing is really crucial. As we in the community has chosen PackageInfo as the standard way of defining what belongs to a package inside the image - this is the connection that binds SM with the workings inside the image and brings SM to a whole new level of usefulness. How is that?

Given this we can easily navigate from a Squeak code element (say a class or a method) using the PackageInfo convention in category naming then finding the PackageInfo name and finally we find the corresponding SMPackage with that name in its PackageInfo name field.

And as I explained earlier we can then also navigate further up and get the SMAccount and thus the name and email of the primary maintainer of the package. We can also easily get the co-maintainers. So all the way from the method up to the person(s) who wrote it. Very useful.

Which brings us to another new feature in SM2 - co-maintainership. In SM1 it was easy to just share the password of an SM entry and thus co-maintain it. In SM2 this option disappeared since SM2 now uses a login form and a session when working in the SM2 web frontend. So we introduced the idea that a package owner can add other people as co-maintainers of a certain package. This means multiple people can make releases and maintain the package entry.

Another important new feature is that now when we have releases we can indulge in the convention that a release is immutable. Sure, this isn't true technically - the maintainer may cange the file contents at the other end of the URL. Or the maintainer may actually change the URL of the package release. But from now on SM2 considers these two practices "bad style".

So, given that releases can be considered immutable - we can now add a client side cache! Yiha. This means that from now on "download" in the package loader actually means "download if not already in cache". And "install" now means "download if not in cache and install". Previously "install" always first downloaded, which was a bit non-intuitive.

The client side cache resides in the "cache" directory below the "sm" directory. It relies on UUIDs of packages and the automatic version number of the packagereleases so it doesn't matter if packages are renamed etc. It is also "filename clash safe", since each release get's its own directory.

The cache is a very interesting new mechanism. It not only saves bandwidth :) but it primarily forms a new base for Squeak distribution. We can now deliver Squeak with the Basic image (or even smaller) together with a suitably filled SM cache. The cache would typically include all package releases including load scripts to get to Full.

A mega Squeak CD can include a cache with almost everything available on SM. As an example, here is a little snippet that caches all releases of all my packages locally: 


(SMSqueakMap default accountForUsername: 'gk') packages do: [:p |
	p releases do: [:rel | nrel isDownloadable ifTrue: [rel ensureInCache]]]
...well, you get the point.

Some other small features - SM2 now actually has a file upload mechanism built in. This may be of less importance to the Monticello users - we just save from the Monticello browser to an ftp repository somewhere. But it is nevertheless a nice feature to have.

Another "nice feature" that I haven't been able to explore much myself yet is that the package descriptions actually support the Swiki syntax now! And it also has some pretty cool smarts for doing links. I will cover that in a separate little article.

And last but not least, how can you write loadscripts in SM2 that take advantage of having releases? Here is an example: 


| map |
map := SMSqueakMap default.


 "This will install the first release of SharedStreams, it does not work if the package is renamed."
map installPackageNamed: 'SharedStreams' autoVersion: '1'.


 "This will install the first release of SharedStreams and does work even if package is renamed."
installPackageWithId: '2bbc04df-fc80-476d-9caa-6877fa938bc2' autoVersion: '1'.
...just look in SMSqueakMap for more methods etc. The nice thing here is that load scripts like the one above will always yield the same result - unless maintainers of course break the rule about immutability of releases. This also means that a script like above can easily be submitted into the update stream because it will have the same effect whenever people decide to load updates.

Over and out, Göran Krampe

cache -> P2P sharing?, posted 19 Jan 2004 by Socinian (Apprentice)

Will the cache also allow for a P2P data store strategy for improved bandwidth sharing?

wow, posted 19 Jan 2004 by cdegroot (Master)

a small step for a Swede, but a giant leap for Squeak

Regarding P2P sharing, posted 20 Jan 2004 by gokr (Master)

Well, not exactly what the cache would need in order to "allow" P2P sharing - and note that the size of Squeak packages are very, very small compared to other things.

What I do want to introduce in 2.x though is a server side cache too. That does though introduce a few issues licensewise (distribution), but it would make it much nicer regarding availability.

[ Home | Articles | Login/Account | People | Projects ]