Hi,

> > I do mind very much if some package thinks
> > it needs to enforce what that package thinks is "good for me".
> ...
> [Reasons to use existing Smalltalk code formats]
> MCV is wonderful for developing stuff. That its format is not
> standard (say, SIF or .st) is a small inconvinience in my mind.
> You can export it to .st. To sum up, you're not forced to force
> your users into anything.

Right. And I didn't claim it. All I said was that I am looking for an option
that gives people the choice between either using "my" package/versioning
system or just install the code without it. And, according to my
understanding, MC is not it.

Then you asked about why not silently install MC and the rest of this
message is concerned with this aspect. Please, let's not mix up the two -
they are entirely unrelated.

> Since I think that all of my users (wearing my RB maintainer 
> hat) could be interested in sending me patches for the RB, and
> this should be easy for them to do, I certainly do find it
> appropriate to install MC for them if it is missing.

Do I want to submit RB patches because I'm playing with SmaCC? Well ... I
don't really think so. In fact it bothered me a lot that loading SmaCC
indirectly broke various, totally unrelated places in the system. For the
reason of RB being broke I didn't want it at all, but thanks for the
smartness (well, okay, requirements, but it's an example anyway ;) of the
package it doesn't even give me that option.

Think about what this "silent loading" scheme means from a system
architecture point of view. Somewhere along the lines of your silent
installation there _will_ be a weak link, a package a little outdated,
making some rather innocent looking change (and I wouldn't call changes like
in RB "innocent"), and the longer the chain, the more likely a problem and
the worse it'll be to track it down.

So I stand by my point: No package should silently install any other package
unless it is clear to the user that this is a basic prerequisite. And it
should only require things that are really _required_ to make it work.
What's wrong with asking the user to install MC if it isn't there?

> > ... against silently loading
> > (or even requiring) some particular package unless it is 
> > needed for what the package itself does
> This basically means that you would disallow the use of alternative
> formats on SM at all, including SAR, projects, and so forth?
> I don't understand this at all. I think alternative formats are
> critical for evolution of how we share stuff, and SAR and MC are
> definite improvements in this area.

That's actually a third issue which is almost completely unrelated to the
above. Let me try to respond briefly: I have _never_ relied for example on
.morph or .pr files for storing anything I really care about. Why? Because
these formats are basically "proprietary", e.g., without having a specific
set of tools (namely: Squeak of that particular version with that particular
set of changes installed) I won't be able do do much if (for example) my
hard disk crashes and I need to get the information out of it without the
"right" set of tools.

I consider the information stored and being accessible from SM to be
important. Introducing further "proprietary" formats for Squeak is something
that we should look at with a lot of caution. Can information being stored
in .mcv format be easily retrieved if something breaks horribly or if we
don't have Monticello in some image and the server is down and we need to
have this package for the demo tomorrow?

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.
As you can see from the above, my distinction between being canonical or not
is not based on text vs. binary (though I do generally prefer text for the
ultimate representation). It's what you can do with the bits If All Else
Fails.

Cheers,
  - Andreas