After a few interesting hiccups with his slides, Alan proceeded to talk about Store futures:
The topics: Shadow Compilation, updated Merge Tool, Glorp as a Store back end, Projects and Streams, and Internationalization (for Store).
Shadow Compiling: motivated by partial code loading - i.e., errors that occur while the code is loading from Store. Source loading involves filing in code from the repository, which can lead to file-in load ordering issues. For instance: you are loading a new version of the Oracle Database Connect while using the Oracle Database Connect as your repository connection.
Parcels obviate these issues by installing code after all the code has been read. Parcels also supports the loading of code that cannot be fully installed (but will be if/when the pre-requisites for it are loaded). Store loading works in one of two ways: Source (like file-in), Binary (like parcel loading). Source loading does handle unloadable definitions better than filing in. Binary loading does not.
So Shadow Compilation: like file-in, compiles source. Like binary, defers installation (loads into a shadow namespace). From the user's point of view, it's an atomic load. This stuff will be included in 7.5, but will not be turned on by default. It's essentially preview (beta). To turn it on:
Store.Bundle useShadowLoader: true.
There will be an option in settings for that.
This next part is mostly demo, of the new merge tool that's been done. It's a much nicer tool now - you'll just have to look at it when 7.5 ships.
Store For Glorp: a Glorp back end for Store. It adds an actual object model to Store. In the process it improves performance, makes for better queries, and supports schema modifications (at present, this is hard). This is in preview now, but a number of people are using it (including Cincom engineers). Features:
- Repository Crawler
- Browse Class Versions
- Store Worksbook - a workspace of useful Store expressions
Projects and Streams: Addresses "configuration management" issues in Store. Very early stage, design level work. We do want feedback.
- Higher level code organization
- Tools aspect of that
- Code management aspect of that
We want projects to be partially loadable, aware of deployment and non-Smalltalk artifacts. We also want to support explicit branching. Streams more or less means a series of versions with branching supported. To do that now, you have to go by naming convention. Streams will allow something akin to Envy "open editions".