One design aspect of MC is that it supports many different "repository
types".  So how about letting Installer install from a "composite"
type -- in fact we already have MCRepositoryGroup which currently
doesn't seem to have a lot of value -- so it could be an opportunity
to make it more worth its weight without introducing any "new" API
complexity.  The install script would just set up the
MCRepositoryGroup instance with the repositories in the order they
want and tell Installer to install normally using same existing API as
the regular repository types (FileBased, etc.).



On Mon, Jan 21, 2013 at 5:04 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> I have a change to InstallerMonticello that allows it to fail over to
> an alternate repository. That means that
>
> Installer ss
>     package: 'Zippers';
>     install: 'Zippers-fbs.52.mcz'.
>
> will attempt to load the mcz from the local cache, but fall over to
> the canonical repository. Alternatively, one could say
>
> Installer ss
>     package: 'Zippers';
>     failover: (Installer ss3 package: 'Zippers'; mc);
>     install: 'Zippers-fbs.52.mcz'.
>
> which would try SqueakSource before falling back to ss3.gemstone.com.
> (I currently don't support multiple failovers, but I should.)
>
> Now to my question: if you try load a file from an
> MCFileBasedRepository that does not exist, you get a
> FileNotFoundException. I think this should be caught, and an MCError
> (which doesn't exist yet, but should) raised. My rationale is this:
> driving Monticello from the outside (like Installer does), I don't
> care about the precise kinds of errors that may occur.
> FileNotFoundException, NameLookupFailure, whatever, I only care that
> MC failed to do something.
>
> In particular, I DO NOT want to catch Error. And, I DO NOT want to
> scatter every possible kind of exception that might occur because a
> user decided to use a GOODS repository and I forgot to figure out what
> kinds of exceptions that kind of repository might throw.
>
> Thoughts? Rethrow underlying exceptions as a generic-but-specific-to-MC MCError?
>
> frank
>