* Ian Clarke <ian at locut.us> [2009-07-27 12:42:11]: > On Mon, Jul 27, 2009 at 6:27 AM, Matthew > Toseland<toad at amphibian.dyndns.org> wrote: > >> > I disagree, php or java reduces performance and increases costs, for all > >> > hosting options. > >> > >> Are you serious? ?I can imagine someone making that kind of argument > >> against dynamic page generation in 1994, but not now. > > > > It happens to be true. On grounds of security, performance and cost. We get > > a lot of hits, and any cheap hosting option, including the Google app > > platform, will be much slower with .php's than with static HTML. > > Well, firstly you can't use PHP on the Google App platform, it has to > be Python or Java, and I suspect in either case it will be as fast as > we could ever need it to be. > > > And we don't want an expensive hosting option: we want to save money. > > Crippling our website to save a few dollars per month (and that is, at > most, all it would be) is extremely short-sighted. Google App Engine > is free up to a pretty high traffic volume AFAIK. I think we'd > probably have a hard time finding hosting that *didn't* support some > form of dynamic page generation. >
Hmmm, Freenet? To do what is proposed (change the download button/text depending on the user-agent/OS), you need redirects: not dynamic page generation. But agreed, that can be done with dynamic page generation too. That being said, it would be nice if fproxy was able to handle such redirections through a special key type for instance. > >> I don't like using Javascript for this, and I certainly don't like the > >> assumption that we are no-longer permitted to do any dynamic page > >> generation server side. ?That is crazy. > > > > We don't use it now. We haven't used it for years, all the php stuff is is > > SSIs, which > > can be compiled in advance. But please step back a bit: we are talking > > about what > > happens *when javascript is turned off*. Only paranoid geeks turn off > > javascript. If > > they have to choose their OS then that's no great hardship for them. > > Except that it appears to be unreliable even with Javascript turned > on. I experienced problems with it in Safari 4 (with Javascript most > assuredly switched on). > That's presumably because you're one of the few using a mac and reading this mailing list :/ It can probably be fixed. > > Of course it is true that all plausible hosting options support php, but > > just because > > they support it doesn't mean that there is any good reason to use it on the > > homepage. > > There is a reason that practically every website on the Internet uses > server-side page generation (PHP or otherwise). > > Declaring that our entire website must be static is an arbitrary, > pointless, and very limiting restriction. > > I'm not aware of a single other website anywhere that has opted to > limit itself to static page generation, either on the grounds of > security or cost. This is because its a crazy argument. > Agreed. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090728/13ea31a4/attachment.pgp>
