On Thursday 04 June 2009 14:06:16 Matthew Toseland 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. > > 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. >
Wrong. We would be serving big files from the Google Release System. The web app could point to the latest release, via https://freenet.appspot.com/ . update.cmd and update.sh would need to be updated to point to the webapp, but the great thing is it has a valid SSL cert. Google Apps could provide email redirects - each email address @freenetproject.org could then be redirected via Gmail. We would still need to get mailing lists from berlios. We would definitely want to use berlios for the existing French wiki. We could either use berlios or google sites for the english wiki. This would have to be recreated from scratch or migrated via a script. Both are problematic. And we still need somewhere to host MANTIS - probably on some developer's system with spare bandwidth (not mine!). That's probably the best free solution. If we pay for something, we get: - File hosting including HTTPS. - Website hosting. - Managed wiki hosting for MediaWiki for the French wiki. - Managed wiki hosting for MediaWiki for a new English wiki which we would have to migrate to, OR - Manual maintenance of the existing Wakka wiki. - Email redirects and on some providers IMAP. - Probably manual maintenance of MANTIS, although Godaddy do managed MANTIS; the question is whether we would be able to import our existing data. If we go for a different bug tracker (jira, trac etc), we have importing issues but it might be managed. We would still use berlios for mailing lists. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090604/8f1fc7b3/attachment.pgp>
