On Thu, Jun 4, 2009 at 9:06 AM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > Nextgens has suggested Google Web Apps more than once. This is a paid service > but with a generous free quota. The free quota will become rather less > generous on June 22nd. Hopefully we will get the release out before then, but > we will definitely have to pay to release 0.8. Details: > - 10GB/day free transfer each way at the moment, 1GB/day after June 22nd. > - 46 CPU hours/day free at the moment, 6.5/day after June 22nd. > > The issue with CPU time is SSL: at the moment, https://checksums redirects to > an HTTP download, ideally we'd like to serve the installer over SSL, > especially since we don't have a code signing cert, but it is not clear how > much CPU time this would cost. Anyway, if we do it as now, we would just > serve the .sha1's etc directly, and redirect to HTTP for the bulk downloads. > In which case we only need to worry about the bandwidth. The cost of > bandwidth is reasonable: 12 cents per gig outgoing, 10 cents per gig > incoming, so $96 for a respectable slashdotting of 100,000 downloads (8MB > each). And in the months when we are not slashdotted, it should cost nothing, > even with billing enabled. > > The default quota only allows 56MB/min, which is only 7 downloads, so may not > be enough for a slashdot to work well, but if we enable billing it increases > to 740MB/min, which is 92 downloads per minute, which is probably sufficient. > > What services could this provide for us? It could certainly provide: > - Hosting static web content over HTTP. > - Any dynamic java-based content we want to add in future. > > I am not sure whether it could provide hosting of large files. Servlets are > required to return within 30 seconds, presumably the output is buffered, but > thousands of 8MB downloads may not be what they intended to buffer. One > serious issue is that we cannot run HTTPS on our own domain name: > > "All secure traffic with Google App Engine must be served from your > appspot.com domain (https://your-app-id.appspot.com). If you are serving your > app off of a Google Apps domain, you must direct all secure traffic through > your app's appspot domain." > > Hence we would not be able to keep https://checksums.freenetproject.org/ even > as a redirect. That eliminates much of the appeal for me, as it breaks > update.cmd / update.sh. Really Google Web Apps is designed for dynamic web > applications, which is not what we are building.
If we can keep some sort of hosting for https://checksums.freenetproject.org up (even some basic free host) or heck even a developer's home server to serve a redirect or an updated version of the update scripts, then backwards compatibility would not be a problem. We would just need this for 6-12 months. Another option would be to have the node write a new version of the update script in the node directory. That should cover 99.9% of cases. > > What does it not provide? > - MANTIS. > - Mailing lists. > - A wiki. > - Probably doesn't provide email redirects. > > Wiki and mailing lists we could probably get from Berlios. > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - Voltaire Those who would give up Liberty, to purchase temporary Safety, deserve neither Liberty nor Safety. - Ben Franklin
