Alex Perry wrote: > 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. > > These debates are pretty pointless. Curt is the webmaster so everything needs to pass him and his standards, which platform , css et all.
I just feel sorry that I've wasted a few days on development in vain. se la vie pete ------------------------------------------------------------------------------ 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
