Re: request for use cases

I suspect these are well covered already  however, here are some use cases I can see, not in pseudo-code form yet, just a brain dump:

- Of course start from absolute minimal image, scriptable loading of everything you want.

- Tools to automate remembering of things you add during day to day work, so that you can reload everything again by script eg. when migrating your working image contents to a new base version..

- When attempting to load a new package, I would like to be notified if the package already exists in the image and whether or not any parts of it have changes in the new. I don't want to just blindly reload a package on top of what was already there.

- When I attempt to load a new package, and something happens during the install, eg. a DNU appears, I would like to be able to be able to completely undo the install and be guaranteed that everything is restored to an identical state to before I started installing that particular package.

- When installing a new package that contains new versions of Classes or methods which are already existing in the image, I would like all previously installed software to continue to work with the previously existing Classes and methods as was the case before the install of the new package was attempted, unless explicitly desired to update previous senders to the new versions.  There should be tools to allow study of the existence of multiple versions of the same named Classes and methods currently 'live' and selectively be able to move some or all incidences of using old versions to new. eg. if Flow could have been loaded even though it changed some core functionality, while maintaining use of all older versions at the same time, it would have been much easier to test out Flow for new development while having confidence everything existing would still work as before. Eventually when desired, migration to all new could be done with appropriate tools.
This would overcome the majority of fear people have of moving forward and breaking backward compatibility.

- Any previously installed version of a package should be completely unloadable to a previous state as though it was never loaded in the first place. If some other package had subsequently utilized some of the loaded package items since it was installed, this should be flagged at the time of attempted unload and the conflicting items could be moved to the package still requiring them. Other options may be needed here too such as creating another new package to hold the still required items that could not be unloaded. Loading and unloading should be guaranteeably undoable so that you can always have confidence there are no side effects.

- A facility for tracking certain ongoing modifications to the image would be beneficial, to be done in such a way that the current state of your working image could be reconstructed from a known starting point such as a new release version. Think taking a release 3.10, running a script to load all the additions to make it a dev image, then continuing on reloading all the stuff you had been working on since the last time you started from a fresh release image. This is currently possible with Installer scripts but it is a manual process to keep adding pertinent work to saved copies of Workspaces, your local Monticello Repository and your custom installer script.

- loading and unloading packages should work the same whether on not you have Internet connectivity as along as you have local copies of required items available. Tools might be required to verify that your image can be restored from local copies to facilitate working in offline mode. Synch tools may be required here. eg. you start working on a new package on your mobile computer while lounging at your mountain cabin or when at the campground in your RV. You have no Internet available there. You get home and you update/sync your more powerful desktop computer so you can do more work there more conveniently with your large screen real estate. You only have dial-up there so you continue working mostly offline but on the desktop system rather than the laptop. You need convenient way to keep the laptop and desktop systems in sync.
At some point you find a high speed connection (eg at Starbucks) so you post your current work from the laptop to an online server somewhere. Later you finally return to the office where you only have a desktop computer and you sync that as well so you can continue your development. This should all be easy and convenient to keep all sync'ed whether or not you have Internet connectivity. Of course the required synch paths will need to be there when needed. eg. laptop to online repository.    

- A variation of this theme would be taking everything with you on a usb storage device to another computer altogether.

Thx,
Ken G. Brown

<>
_______________________________________________
Spoon mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon

      Thanks, Ken!


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

_______________________________________________
Spoon mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/spoon