Yes. So how do we do that? Dale can we use the ssgemstone you host? Stef
The problem is that the network operator is down...
see http://code.google.com/p/pharo/issues/detail?id=4218
We should really t hink hard about redundancy...
On 14 May 2011, at 09:54, Stéphane Ducasse wrote:
Yes. So how do we do that? Dale can we use the ssgemstone you host?
Stef
The problem is that the network operator is down...
see http://code.google.com/p/pharo/issues/detail?id=4218
We should really t hink hard about redundancy...
I think Amazon AWS S3, like Marcus suggested, is one way to go. What if we build a bot (a Smalltalk image running somewhere) that periodically (say every 5 or 10 minutes) checks a specific number of important/critical Monticello compatible repositories and then syncs and if necessary copies versions to a properly structured (public readonly) S3 namespace. S3 is just plain HTTP hosted data, so adding this to MC is already possible today, as a fallback like Lukas suggested. Amazon S3âs standard storage is: ⢠Backed with the Amazon S3 Service Level Agreement. ⢠Designed to provide 99.999999999% durability and 99.99% availability of objects over a given year. ⢠Designed to sustain the concurrent loss of data in two facilities. It costs some money, but not much (it is pay as you go). Sven PS: Yes, I known the following question ;-)
On 14 May 2011, at 11:55, Sven Van Caekenberghe wrote:
S3 is just plain HTTP hosted data, so adding this to MC is already possible today, as a fallback like Lukas suggested.
Well, there is one problem: listing a repository won't be compatible, that is OK for Gofer I think, but the MC GUI will have a problem with that. We could fix that with another MCFileBasedRepository subclass.
I started to review all the fixes made in squeak by chris on monticello and I should slowly start to integrate them. But I need time :) Stef
S3 is just plain HTTP hosted data, so adding this to MC is already possible today, as a fallback like Lukas suggested.
Well, there is one problem: listing a repository won't be compatible, that is OK for Gofer I think, but the MC GUI will have a problem with that. We could fix that with another MCFileBasedRepository subclass.
Stef, GemSource is running Seaside2.6 and a very old version of the SqueakSource code. I'd rather run Seaside3.0 and Tobias' SqueakSource3 as an alternative to SqueakSource. And as a matter of fact, we have already started heading down that path. While I was on vacation we had a vm provisioned in a VMware data center for hosting a SqueakSource3 instance:) The plan is to run the SqueakSource3 instance as a beta for a couple of weeks to correct any load/code issues and then barring any big issues, open it up for general usage. I'll need a week or so to get the GemStone and SqueakSource3 installed and configured. When the beta is ready I'll send email to the list ... Dale On May 14, 2011, at 12:54 AM, Stéphane Ducasse wrote:
Yes. So how do we do that? Dale can we use the ssgemstone you host?
Stef
The problem is that the network operator is down...
see http://code.google.com/p/pharo/issues/detail?id=4218
We should really t hink hard about redundancy...
OK thanks for the update. Stef
Stef,
GemSource is running Seaside2.6 and a very old version of the SqueakSource code. I'd rather run Seaside3.0 and Tobias' SqueakSource3 as an alternative to SqueakSource.
And as a matter of fact, we have already started heading down that path.
While I was on vacation we had a vm provisioned in a VMware data center for hosting a SqueakSource3 instance:)
The plan is to run the SqueakSource3 instance as a beta for a couple of weeks to correct any load/code issues and then barring any big issues, open it up for general usage.
I'll need a week or so to get the GemStone and SqueakSource3 installed and configured.
When the beta is ready I'll send email to the list ...
Dale
On May 14, 2011, at 12:54 AM, Stéphane Ducasse wrote:
Yes. So how do we do that? Dale can we use the ssgemstone you host?
Stef
The problem is that the network operator is down...
see http://code.google.com/p/pharo/issues/detail?id=4218
We should really t hink hard about redundancy...
participants (3)
-
Dale Henrichs -
Stéphane Ducasse -
Sven Van Caekenberghe