.mcv => .sar?

Daniel Vainsencher danielv at netvision.net.il
Tue Jul 29 09:00:12 UTC 2003


The idea of using SARs as glue to combine code with versioning data
sounds great.

I have a problem with the part of your proposal in which the preamble
decides what to do with the code, but this isn't unique to your
proposal, SARs have always had preambles.

The problem is this - all packaging brains should sit outside the
packages. The packages should include contents only.

Why? because if the packages are dumb, the packaging system can be
flexible. SM/SMLoader should not have merely two possible actions
install/download. It should have different actions, depending on the
package entry (categories and file ending, for example). An
SMMCInstaller should be queried for it's services, and then provide the
same services available in the file list - open/load/merge.

One of the benefits of this approach, is that the SMInstallers could be
told to work in batch mode - no questions asked. This is important in
order to make package installation a smooth process. While I agree with
the sentiment that things happening "silently" is not good, this should
be a mode that is available, even if it isn't used for regular
installations. A good example is the TestServer that needs to load
packages in order to achieve a certain test configuration, and would be
simpler if it didn't meet various dialogs.

Specifically for this proposal, it is the installer that should make the
decision (possibly querying the user), not the preamble code.

Daniel

Avi Bryant <avi at beta4.com> wrote:
> Just a half-formed late night thought:
> 
> We'd like Monticello to support a number of different formats - for
> Smalltalk source code, this could include .st, .mc, .sif, .pst,
> Rosetta, and maybe others.  For other kinds of packages (and I don't see
> any reason why there couldn't be other kinds), there would be an entirely
> different set of possible formats.
> 
> However, the contents of each of those formats maps to what Monticello
> calls a "Snapshot" - the collection of definitions being versioned,
> without any particular ancestry or packaging metadata attached to them.
> But what we generally want to be passing around are Versions, which
> contain a Snapshot plus all the necessary extra bits of info.
> 
> We'd fuzzily been thinking that each format would have some semi-natural
> way of including this metadata - annotations for SIF, maybe a preamble
> comment for .st, and so on.  But this is pretty adhoc and doesn't feel
> quite right.
> 
> What about taking a page from Ned's book and making the format be a ZIP
> file?  You could have special paths monticello/package,
> monticello/version_info which contained the metadata, and
> monticello/snapshot which explained (as a SAR-like install script,
> perhaps) how to recreate the Snapshot from whatever other members (like
> "source.sif", say) were in the ZIP.
> 
> They could in fact be SAR files, whose install script checked for the
> presence of Monticello.  If it was there, they wouldn't directly install
> anything but instead would pop up the Version window from which you can
> load, merge, etc.  If there was no Monticello they would load themselves
> into the image as best they could.
> 
> How does this sit with people?
> 
> Avi



More information about the Squeak-dev mailing list