Hi all!

As our box1 (the UML box) is coming to an end after faithful service
SqueakMap will be moved to box2. This is of little interest to most
people since we should be able to do it transparently - with just a very
quick pause of the server.

The new URL for the SqueakMap master server will be
http://map.squeak.org (no "/sm" needed) but the old URL should also work
so that old clients aren't totally lost. When updating the next time
(after the move and upgrade) you will be asked to upgrade SM and
everything should go smooth.

The move is of course a good opportunity to give SM a little "code love"
and the rest of this email describes what I have done with it for this
release called 2.1. There are also tons of other nice things pending in
plans and todo lists etc, and I also need to "sweep" the net for fixes
including Mantis and I think there might be fixes inside 3.9 that hasn't
been sent to me too.

After this update the next release (2.2 or 3.0) should be a rather
radical change - going for a fully distributed model instead of the
current "monolithic but replicated" model. It should also include a
working dependency mechanism - I have my own code which got stalled and
we also have Kabungu, which I intended to integrate one way or the other
- but haven't decided exactly how to tackle it, see below.

Enough chit-chat, here goes:

General upgrade
===================
The Squeak base image for the server has been upgraded to 3.7 with the latest KomHttpServer and HV which I now also have improved even more. Since HV had evolved quite a bit since the last SM release, the web UIs needed some tender care to work properly again, but it should be more robust now. I will also add the VNC package to the server image so that I can more easily maintain it - Ian, you rock btw.

Server side cache
====================
The download URLs for the releases in SM point to the original site, if the file isn't actually uploaded to the account on the SM server itself. As we all know servers go down or they simple are taken offline accidentally. SM 2.1 now has a server side cache so that whenever you *add a release* or *change the download URL* of a release it will fork a download on the SM server in the background populating a proper cache on the SM master server.

Then when the client tries to download a release it first tries the original URL, and if that fails it goes to the SM server and downloads from there instead. The Exception handling should need an overhaul, but another day... :)

SHA checksums
=================
In order to make the client and server side cache more robust each release now has a SHA checksum. This checksum is calculated when the server updates its cache (see above) and the user registering releases should *ideally* verify that the server side cached file is correct.

This checksum is then used whenever someone downloads the file, either from original URL or the server cache. If the original URL returns something with the wrong checksum it will be considered a failure and it will try the server cache instead. This will "catch" most of the various HTTP error responses that SM earlier mistakenly thought was the actual release content.

Package transfer
====================
Ownership of packages can now be transferred to another account. It is a feature of the edit form of the package. Just make sure you do it right, because you can't pull it back. :)

Two new package fields
============================
In order to be able to improve the tools in Squeak for simpler feedback on packages I have now added two new fields: feedbackEmail and repository. The feedbackEmail is an email address that the tools can use to send error reports, fixes or whatever instead of relying on the email of the account. This could for example be a developer list that has been setup for the package maintainers.

The repository field is meant to refer to the active development repository for the package - currently that would be an MC repository. I am unsure of the syntax for this field - is there some kind of URLish syntax we could use or do we need to use a Smalltalk expression (like MC does when creating repos) for now?

Release branching
======================
When creating a new release the ability to select the parent release has given us the ability to branch. Unfortunately the VersionNumber package is b0rken IMHO since it uses a simplified version numbering scheme that effectively creates a binary tree - in other words only *one* new branch can be created from each parent release. Duh... I would like to revisit VersionNumber and move it to a more "CVS like" numbering scheme, but have postponed it.

The ability to branch is of course good for maintaining "release branches" or for maintaining several branches based on Squeak version (avoiding having to create multiple SM packages, like Refactoring Browser does today).

It is also good for the upcoming "unofficial release" feature, which I am also postponing - but which will make it possibly for another account to publish a release of a package that is not co-maintained nor owned. These "unofficial releases" form a more direct way of being able to publish large improvements to existing packages so that people can try them, without having to create a competing package while waiting for the enhancements to be integrated into the package itself.

Kabungu integration
========================
Kabungu is a good and working model for defining and maintaining dependencies in SM. Michal Starke wrote it and since I like the model (a mix and refinement of existing thoughts and models) I decided earlier (but unsure today) to just adopt it without any fuss. I was aiming to have it included in SM 2.1 in one way or the other, but I have to "punt" on that one.

My own model only differs slightly and can be seen as a complimentary mechanism that might be interesting in the future, but the need might never come if Kabungu's model proves to work as intended. Kabungu is primarily a client side implementation and it only needs a bit of state "attached" to the package releases.

Exactly how the Kabungu integration will move forward is a bit unclear right now since the future of Kabungu is a bit unclear. But that is a whole different story and in one way or the other I expect either the Kabungu code to get integrated or my own code to get finished. :)

Fixes
=====
And finally I have resolved a bunch of bugs and cleaned out tons of old crap.

Note: There are now some classes in the SM base that aren't used - these are my draft classes for my dependency model. I left them in, but might take them out later or simply go all the way with it, we will see.


A request for help
=====================
As many of you know the SqueakMap Package Loader has a nasty habit of being either white or even translucent (in 3.9!) in some Squeak versions - and just perfectly yellowish in others.

I have tried hard to copy how SUnit is built regarding this - but evidently something is awry. I am pretty damn sure it has to do with the simple fact that SMLoader is a *subclass* of SystemWindow (just like the  zip ArchiveViewer is/was (not sure if it still is)).

A long time ago I found the little dark corner in the code that was in need of a change so that SMLoader and ArchiveViewer should not be white (it basically was a check to see that if there was no model to ask for colors you would ask self instead) - but that was before that code was refactored/changed/whatever because today I am utterly lost in there and also a bit tired of it all. :)

So please, pretty please with sugar on top - can someone tell me how to fix this? Also, while you are at it - it would be nice to get SMLoader into the tool flap - I think I have done all the preparations for it - but we also need to somehow recreate the flap. Any ideas on how we deal with that in this new brave world?

regards, Göran

PS. Cees broke the 600-packages-on-SM-wall the other day. Yiha! Impressive.