thanks for the analysis. Let us what other things. We will really hosted and use the inria infrastructure for the key elements in the future. Now I will ask them mid august when we can have it. but I like the idea of mirroring.
On Jul 22, 2010, at 10:34 AM, Norbert Hartl wrote: > Would be nice if there would be a few people discussing the trade-offs. As my > current project comes slowly to an end I will find some time to be active in > this. > > My proposal would go like this: > > - the most important thing to achieve is to have sources of projects available > - in the beginning we can live with a setup that might be a "little" > cumbersome to use > > A first solution that is easy to set up and that is reliable is: > > - www.squeaksource.com is the master where all projects are created > - mirrors copy source files via rsync to distant machines and provide WebDAV > shares with the same directory layout as squeaksource > - squeaksources WebDAV is read-write while the mirrors WebDAVs are read-only. > This way rsync is already the best choice. There can be only data transfered > from squeaksource to a mirror > > > What use case will be feasible: > > - a user searches for a project on squeaksource and copies the MC http > repository snippet in his monticello browser > - now the user has the central read-write location at his side. > - if squeaksource is down a user picks another http repository from a list of > mirros, enters it in monticello and downloads source from the new location > - if the user is a developer and wants to store a project change now gets an > error if he tries to store it on the mirror. The developer than just clicks > on the central location and stores it there > > Things to solve: > > - where is the list of mirrors maintained > - how would tools like metacello copy with different locations. I know there > is support for alternate locations but AFAIK only if there are placed inside > the ConfigurationOfxxx. I don't think it is an option to put in mirror > locations in the ConfigurationOfxxx. > - files can still be uploaded to squeaksource more or less "anonymously" > which interferes with inria policies > > So far... > > Norbert > > On 22.07.2010, at 10:08, Stéphane Ducasse wrote: > >> ok thanks for the explanation. >> Now I do not know who have the time to build such a set up. >> If we can prototype a version then >> we could after offer to have it maintain by the inria engineers and this is >> good because >> it will reinforce also our presence inside. >> >> >>>>>> how your server is backed up? >>>>>> Then we should pay attention not to end u having multiple of sources >>>>>> around before we can deal with the mess >>>>>> this may create. >>>>>> We got the ok from inria for a webdav server (the problem was that from >>>>>> a security view point, having >>>>>> an anonymous write was a no go. So now we will do >>>>>> - write only inbox >>>>>> - inputs are then checked to be only .mcz >>>>>> - then automatically copied to a readonly inbox >>>>>> - pharo* projects should be >>>>>> read and write for the people registered to the forge. >>>>> >>>>> >>>>> Great, this is only for Pharo or you want to mirror also Squeak projects ? >>>> >>>> We do not know. For now at least the Pharo* repositories and the ones that >>>> are central XML-.... >>>> Ideally I would prefer to have everything in the same place and we have no >>>> problem hosting squeak projects. >>>> Now what is more important is build a kind of process to clean projects, >>>> there are a lot of projects which got created >>>> but >>>> - were never really used >>>> - are students code exercises >>>> So may be starting with a metacello config for every working one could be >>>> a start. >>>> >>>> The problem is that you lose all the nice aspects of squeak-source: UI to >>>> manage the commiters..... >>>> So we should check with the effort of dale and philippe and others on the >>>> gemstone version of squeaksource. >>>> >>> I don't think you loose anything. You need to separate write and read. You >>> still create a project on squeaksource and this creates a WebDav directory >>> for it. If the mirrors sync than this project is replicated to all other >>> mirrors. From this point in time a client can just use a list of mirrors to >>> fetch the source from a different server if the master is down. It is easy >>> as this. No need to install squeaksource on the mirrors. This scenario even >>> applies if you take the gemstone based squeaksource into account. To me it >>> is really just a matter of who is doing the failover handling: user or >>> client. >>> >>> Norbert >>> >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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
