On 6/19/05, Bert Freudenberg bert@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