SqueakLoad is a way of booting Squeak in a deployed environment.

Status: not yet designed or written.

SqueakLoad allows for the easy and automated starting, upgrading and installing of Squeak. Typically, a small "object" file will be made available to the user either on the desktop, from a web page or in an email. This "object" file has a MIME handler or application association in the operating system to SqueakLoad. When the user double-clicks it, or runs "see" under Linux (refer see(1)), or opens it from an email or web page, the SqueakLoad executable will fire up and look at that file, and then download (and cache) a VM and image file that can handle that file.

Say, for example, that the file extension ".sqo" meaning "Squeak Object" is used. Assume that Windows is being used and a .sqo file is on the desktop. When the user double-clicks on that file, SqueakLoad will load that file via the file association mechanism on Windows, and then download and run a VM and image referred to in that file using URLs.

On Linux and Mac, the same file association mechanism could be used.

SqueakLoad could potentially be a standard application written in Squeak which can fork off and manage a second VM.

The .sqo file would contain:

• an optional URL pointing to a VM. Note that the .sqo file needs to be platform independent, so some mechanism will need to be invented to make sure that the right VM for the current platform is loaded. If omitted, any usable Squeak VM would be used.
• a URL pointing to an image that can handle the given file.
• data; this data is passed to the image and it is assumed that the image knows what to do with that data. For example, the data might be a reference to a distributed object, or it might be another URL referring to a .pr file.

SqueakLoad functionality wishlist

SqueakLoad should be able to:

• download and run a specified VM for the current platform in use.
• download and use a specified image.
• use a cached copy of the image and VM if they are locally available.
• connect with an already-running version of that VM and image if they are already active.
• run in "daemon" mode in the background for services such as Seaside.
• run the downloaded VM with the specified image, and pass the data in the object file to that image.
• gracefully handle an image or VM crash. SqueakLoad might automatically restart the VM or give the user the option of sending in a bug report.
• gracefully handle errors, such as when no network connection can be made.
• maybe handle logging facilities for that VM.
• periodically check for updated versions of that image and VM, upgrade them and handle restarting them. This might potentially need to happen without user intervention if running in "daemon" mode.
• If an image is upgraded, some mechanism (*wave hands in air*) needs to be used to move user data from the old image to the new one.
• Upgrade itself.
• Use some form of HTTP authentication with credentials provided in the object file. This prevents the general public from getting at the VM and image without having an object file.
• Be able to detect and use HTTP proxy settings on various platforms.
• Start the object file with a #!squeak so that it can be used as a script.

Remote VM manager

This is a separate wishlist for a potential remote VM management application:

• Start, stop a remote VM remotely.
• Remotely specify which VM and image should be used on remote servers (with automatic uploading).
• Heartbeat, restarting of dead services, reporting of dead services to some service mananger.

Links

http://en.wikipedia.org/wiki/File_association