2. Repositories, storing, loading and unloading; sharing modules on the net

• Modules and DeltaModules can be stored into and installed from repositories, either on your local disk or from the internet. This uses ftp for uploads and http for downloads. See also A simple Module example.
• Some examples have been created to demonstrate how easy it is to install and use modules that have been uploaded to the net. These are some existing Squeak projects that have been converted to modules. You can try each one of these separately:

    ModuleInstaller fullyInstallFromPath: #(People hg ModuleDemos di KidsRefrigeratorMagnets)
      	"Then try: (KidsRefrigeratorMagnet newGame)"

    ModuleInstaller fullyInstallFromPath: #(People hg ModuleDemos nk MagneticPoetry)
      	"NCMagnetRefrigerator setup"

    ModuleInstaller fullyInstallFromPath: #(People hg ModuleDemos nk Connectors)
      	"NCButtonBar newClassDiagramToolbar openInWorld.
	     	 NCButtonBar newFSMToolbar openInWorld"
    ModuleInstaller fullyInstallFromPath: #(People hg ModuleDemos Comanche Swiki)
        ""ComSwikiLauncher openAsMorph""

    ModuleInstaller fullyInstallFromPath: #(People hg ModuleDemos Comanche Kom Core)

• Keep the Transcript open to see progress messages, there are hooks for a proper progress dialog for the inclined. The last example loads just the core of Comanche without the Swiki module.
• Note that these are just demos, not properly modularized, well-structured module versions of the above packages. All the demos were converted using the techniques described in How to port old code to modules.
• These packages depend on each other, and the dependencies are handled automatically by the ModuleInstaller. Note the new preference in the modules panel that controls access to remote repositories.
• There is a module repository at http://modules.squeakfoundation.org where anyone can get a login (their method initials) and password so that they can upload and share their code. With this login you gain full control of the space under #(People [your method initials]). Cf. the use of #(People hg) above.
• Modules can be removed (unloaded) from the image.
  • This works for all modules that you load, as in the examples above.
  • It also works for modules that are part of the image, given that they have been refactored so that they can be unloaded safely. Until the image has been refactored into separable modules (see below), unloading a critical part of the image may crash Squeak.
  • Some modules in the image can already be unloaded safely since they have been refactored (see below).
  • The refactoring effort to turn the image into cleanly loadable/unloadable units is an important activity that you must help with if you want it to happen. See Progress report and to-do list for modularizing the image.

3. Refactoring the image into a modular format

• The FileList no longer holds references to all the classes that implement services for it.
• There are tools for analyzing bad dependencies that should be removed by refactoring, plus a mechanism for defining and distrbuting such refactorings (by subclassing ModuleRefactorer. These are explicit made so that anyone can contribute refactorings, there is a description of this process at A guide to modularizing the image.

• VMConstruction has been refactored so that it, including code for all plugins, can be unloaded from the image (but not yet reloaded because of circular dependencies).
• Balloon3D as a whole, or parts of it (Alice, Wonderlands), can be unloaded safely too.