[A pluggable architecture for Installers]
This could help us get the most out of the information SqueakMap makes
available.

Well, first a summary of where we are and what functionality we want to
get.

Right now we have several responsibilities bunched up together, we might
want to separate, that are all handled by the installers -
- Getting something from the net and saving it locally
- Decompressing it
- Unpacking (for sar files)
- Installing

And we want to add more logical operations on the code delivered, such
as -
- Upgrade/uninstall/reinstall
- 'browse code' (regular or maybe via DVS)

And I think we will also want to enable more operations on the package
itself (not just the downloaded code), like:
- Upload my changes to this package as a new version and update the SM
entry, asking me for the required details. (I'm the maintainer for the
code and the SM card)
- Post my changes to this package to the mailing list, as a suggested
patch (I'm a user and contributor).

I'm assuming this covers more or less what we'll need soon. Any other
ideas?

Now, a design proposal (basically, the dynamicOpenMenu design
reapplied)-

If we want to have all these services available in the UI, we need to
have proper registration of services that want to handle packages,
including how they should be displayed in a menu. Then, when generating
the menu for a select package, we do a 
(services select: [:service | service canHandle: aSMCard]) do: [:service
| aMenu add: (service menuSpec)].

Services register when their class is installed, so people can freely
add SM packages that implement new package handling services, including
handling new card types, such as .pr files.

How about it?

Daniel