StORE Usage Page - What your team's usage patterns?
Bruce Samuelson started an issues request regarding StORE. The comp.lang.smalltalk conversation has been Wiki-ized here.
Please include comments on the Commentary pages. If adding a new topic, please create a commentary page.
1. In the class and hierarchy browsers, add a 4th pane in the top frame showing which packages define methods for the class, like Envy does with apps. Make it multiselectable.
Commentary
2. Like Envy, make the protocol pane be multiselectable such that it shows you the selectors when you multiselect rather than showing you nothing.
Commentary
3. Sort lists in various browsers, such as bundles, packages, and protocols. There's no point in having long lists that aren't sorted.
Commentary
4. In the various class browsers, when you select a method, display the package name in which the method is defined. Envy does this for apps and is a convenience so you don't have to always query for the containing package. I think it uses a little space at the bottom of the browser window.
Commentary
5. Make it easier to move methods to a different protocol. At least pop up a list of choices.
Commentary
6. Make it easier to extend a class with a method in a package. The technique I was told is to create the method in an existing package and then move it. That's cumbersome and non-intuitive.
Commentary
7. Have the change list keep track of movements of methods to different packages. A bug in 5i.1 is that it fails to do this.
Commentary
8. View differences between two non-loaded versions. Envy does this easily and quickly.
Commentary
9. Shadow browsers (does StORE have any?) of non-loaded packages and classes.
Commentary
10. Better speed whan loading packages.
Commentary
11. Better speed when comparing differences. It is glacial, at least where I work. It takes minutes to compare what Envy could compare in seconds.
Commentary
12. Make sure that all fileout formats keep track of the package in which the class or method is defined. I've been told that not all fileouts do this.
Commentary
13. Reverse search through the changes file. For example, you get a bad crash and haven't backed up your image or done fileouts for hours. It takes forever for VisualWorks to parse its way through the changes file before you can work with it. Ours run over 30 MB. If reverse search is too hard, at least provide an accelerated forward search in which you pass over everything prior to the last snapshot, or the last N snapshots. In other words, don't parse the first 29 MB if you're only interested in the last 1 MB.
Commentary
14. Documentation for all the change list menus. What do they all mean??
Commentary
15. How about not considering loading a package to be a bunch of changes. Loading a parcel isn't.-Chris Lopeman
Commentary
16. Lets put a menu on the Store connect page to choose your connection type to the Store Database. Same Machine, LAN, WAN, Internet. Use this to adjust the timeout setting for a request. It is hardcoded to 200 ms. This is pretty borderline for Internet. I think that about 50% of my requests timeout and get retried. This increases network traffic and slows loads in 2 ways. -Chris Lopeman
Commentary
17. When you accidently change a method that belongs to a different package, you are given the choice "Override" or "Replace". Unfortunately, most of the time I've made a mistake and really wanted to keep the method in the original package. There's no option for that and no option to cancel. David Buck
Commentary
18. StORE for SQL Server shouldn't require 'sa' access to create databases. David Buck
Commentary
19. StORE should be able to store arbitrary files also. First you often need several support files with the code (data files, configuration files, sql-files) and second the general move in configuration management is, to have one tools that can archive all files and documentation associatated with a particular program version. Carsten Haerle
Commentary
20. StORE should install completely and easily straight out of the box.
A straightforward installation would include:
- Auto-Installation of StORE's required DB, configured appropriately. This could be a "free" RDB.
- All available parcels should be pre-loaded into the default StORE DB's configuration for easy loading.
- There should be a base StORE image that "matches" the default store repository with all code in the image represented in the repository (to the extent possible with all exceptions and their limitations documented).
- All packages (from the available parcels) in the repository should be loadable without error, with all dependencies well handled.
Basically everyone that tries to use StORE needs to address many of these points and winds up going through the long process of re-inventing the solutions and procedures required.
A nice bonus would be the automatic configuration of StORE for access to the CINCOM repository. Bert Barabas
Commentary
21. I should be able to use Store on Store.
Store has a couple of severe limitations:
- Code to be published must be present in the image.
- Code from a repository cannot be loaded over "live" code in the image.
As an example of the former, I extended StoreBase to accomodate Sybase. I wanted to publish both the original StoreBase and my extended version to a Sybase repository. It is impossible to publish the original StoreBase to a Sybase repository, because if the original StoreBase is loaded in the image, publishing to Sybase will not work.
As an example of the latter, Version 1.011 of StoreForPostgreSQL cannot be loaded into an image from a PostgreSQL Store repository -- one must download a parcel instead. Carl Mascott
Commentary