iSqueak

[Avi Bryant]

On 6/19/05, Bert Freudenberg <bert at impara.de> wrote:

> (*) Basically, an MCConfiguration is just the dependencies part of an
> MCVersion. It's the reification of that "versions without code"
> concept others have been using. It probably would be a good idea to
> unify both, or to factor out the dependencies from the versions.

Personally I'd be in favor of simply ripping out the dependencies code
from MC proper and having MCConfiguration be the recommended way of
managing such things.  It feels better to me as a separate layer.  If
we did that, we should probably roll it into the main MC distribution
so people don't have to install both.

> Is there anything planned along that direction in MC2?

Well, in MC2, the ancestry metadata is maintained at the definition
level rather than the package level.  Each version of a method, for
example, has a separate ID, can be pulled separately from the
repository, etc.  There's no longer any requirement to do a load or
merge at package granularity: although we expect that especially at
first, people will send around some equivalent to MC's package
versions (which will just be package name and a list of method IDs),
you could also distribute a changeset (still a list of method IDs, but
a smaller one, with no associated package information), or a full
configuration (a very large list of method IDs + several package
names).  Or maybe there would be other more structured mechanisms with
more indirection around names and version numbers and so on; for now
we've mostly been focusing on the lower level mechanisms.  Work is
moving very, very slowly though, because both Colin and I are too busy
with other things.  It might be a reasonable time to get some outside
help, if anyone's interested...

Avi