What if use redudancy features of Internet itself? As you know the Internet was designed to withstand a nuclear attack, with a lot of redudant features, which we can explore to harden the Smalltalk infracture as well.
In the similar ways as guyss like Google do. You know, they have always a single entry, http://www.google.com, but actually they direct your search to 1000s and milions of their servers behind. A mini version of Google can be use for Squeak or PharoSource as well. As I can see the Monticello repositories are basically the stateless WebDAV enabled Apache web servers. So having a mirror is a first thing to do. To still have a single entry point like http://www.squeaksource.com), we can exploit the redundancy feature of DNS: round robin entries. That is, you enter two entries in DNS zone, with the same name but different IP addresses, say: squeaksource.com www IN A 87.54.32.108 www IN A 212.18.45.87 This way in the case of failure of one server, the another one will responds. If both are working, DNS will return one of them in roun robin fashion. This will work for WebDAV part of the story, but we still need to tackle of the statefull web application of SqueakSource... hmm, a bit more thinking is needed therefore... Best regards Janko On 23. 02. 2010 19:48, Dale Henrichs wrote: > I like the notion of a secondary repository for packages. It is absolutely > necessary to protect us from a catastrophic failure with any one of the > SqueakSource repositories. > > Perhaps Gofer can be provided with a secondary repository location in the > case when the primary repository fails. > > With this kind of approach, the metacello configurations can continue to > reference the primary development repository, in this way we might just be > able to have our cake and eat it too:) The Pharo secondary repository would > protect users from repository volatility and package volatility ... Once a > version is published in Pharo you can count of being able to load that > version over time. > > This secondary repository could be maintained by periodically scanning the > Pharo configurations and copying the referenced packages from the primary > repository to a known secondary repository (this repository could just be > done with Apache file access since a fancy UI for the secondary repository > isn't essential). > > Having code and processes in place means that individuals can reuse the code > and process to maintain their own secondary repository for their own > production environment. > > I have code that does most of what is needed, as I use this process at > GemStone for archiving the configurations and mcz packages in our company > source code control system. > > Dale > ----- "Göran Krampe" <[email protected]> wrote: > > | Miguel Enrique Cobá Martinez wrote: > | > El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribió: > | > I was thinking about this problem yesterday in the light of the > | packages > | > moved by Lukas. > | > We have a problem with the packages referenced by a > | ConfigurationOfXXX. > | > The can disappear anytime. The repository can disappear anytime. > | > > | > So I thought that we need a dedicated hosting server where: > | > > | > - We have all the ConfigurationOfXXX (in the MetacelloRepository > | repo, > | > just as now) > | > - We copy there *all* the packages that conform a giver > | > ConfigurationOfXXX>>versionXX: from the original repo to this > | dedicated > | > repo. > | > - There is *no way* to delete anything. This is a *write only, read > | > always, delete never* repository. > | > | Sidenote: SqueakMap actually caches all URLs used for versions and if > | the original URL fails an SHA check it falls back on the cached file > | on > | the SqueakMap server. > | > | In that way it was meant to handle original URLs going stale or > | disappearing. > | > | regards, Göran > | > | > | _______________________________________________ > | Pharo-project mailing list > | [email protected] > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
