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&#174; 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

Reply via email to