> For this reason alone, I would be hard pressed to use anything I don't
> consider "canonical". Here, canonical means that given what one can
> reasonably expect to have on ones machine, can I get to the information in a
> reasonable amount of time? Will support for it be around for the next twenty
> to fifty years? Let's look at what you mention in the above:
> * Chunk format: As long as I have any version of Squeak or anything that
> smells just a little bit like ST80, I will be able to get to it. It's simple
> enough that I could (if I had to) write a chunk parser in an hour regardless
> of language.
> * SAR format: Essentially, chunk format, but with a .zip structure so if you
> have any tool which deals with .zip files you rename the SAR to .zip,
> extract it and go from there.
> * MCV: ??? I don't know.

I'll try to answer the rest of this thread later as I get a chance to read
it, but FWIW: I wrote a bootstrap loader for Monticello to allow me to
load .mc and .mcv files without having Monticello loaded (this was so I
could feel perfectly safe with managing Monticello itself as a .mc).

MCBootstrapLoader linesOfCode "66"

And Monticello is barely a properitary format - it's a series of
#storeStrings of objects representing class and method definitions in
pretty obvious ways.  Any smalltalker could write a "parser" for this
quite trivially.

However, I also have absolutely zero investment in .mcv as a format.
It's irrelavant.  Nothing in the system cares what the external
representation is, this was just a very simple format to parse (Compiler
readFrom: ...).  If, as I'm sensing, people would like Monticello to have
a format that is a backwards compatible extension of standard chunk format
(or Rosetta, or the VW XML fileOut format, or whatever else) it's really
quite trivial to support any or all of those.  I really hate to hear "I
can't use Monticello *because* the format is X"; I'd much rather "I can't
use Monticello *unless* the format is Y".