On Tue, Mar 9, 2010 at 2:56 AM, Pete Morgan <ac...@daffodil.uk.com> wrote: >> - Do we want to lock ourselves into google? > These issues worry me also, and indeed pointing www.flightgear.org to > fg-www.appspot.com is likely to have other problems (major 404's will > need to be handled)
We should be able to design all the website so it can serve off someone's local machine, in addition to the GAE. Personally, I think as an open source project, we need to be _able_ to serve on an independent platform even if the primary webserver is GAE. As was mentioned previously, especially if we use Django ... there should be nothing that we can't easily do off-GAE. I'm tempted to suggest that 'www-disaster.flightgear.org' should continue to be a Curt-managed machine somewhere. Give it an intentionally bandwidth limited Internet connection and ensure it is always running the up to date non-GAE build of the website. That way, we can easily detect when we've accidentally built a GAE dependency into our web codebase. There is the mild concern that (over time) we get our bandwidth usage up to the point where we can no longer afford to host the content on our own machines at need. If we want to prepare for that possibility, which would not be entirely a bad thing, it might be worth keeping the GAE application broken into several pieces, to separate the bits which are serving mostly-static content separate from the ones doing database accesses. Then, if we ever have the need to move off GAE and are running a lot of bandwidth, we can dedicate one server to the database and round robin all the other content across a lot of other servers. > A Major issues is that GAE does not support binary files very well, eg > gallery, so I'm not sure how this would work. One possibility would be > to rename the current machine as "www2." or "stash." and using it as the > binary storage. I've never had any trouble using GAE to serve binary files, providing they're not ridiculously large (such as huge binary tarballs). As I recall, its web server by default doesn't infer content types so you have to set them yourself on dynamic content. If you still see issues, feel free to invite me to the relevant codebase and I'm happy to take poke around. > The main site fg-www has no database, so the design could be ported to > the current site quite easily, as it used the Django templating engine. > > Does the current server have python or php installed ? >> >> We might decide that none of these issues are an overriding concern. >> [...] I'd be SOL if google evaporated >> from the planet. So what's one more dependency? > Maybe we should ask Google to sponsor FlightGear? Without speaking for the open source program office, I suspect the answer would be that they're very happy to continue sponsoring FlightGear by providing infrastructure that lets the project focus on its own goals ... autonomously. The things like Project Hosting, GSoC, GAE, conferences, etc ... are all trying to avoid pushing any guidance onto the open source projects that take advantage of them. I like that. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel