Posted by d on 10/23/60 11:38

"Steve" <ThisOne@Aint.Valid> wrote in message
news:pan.2006.01.27.03.17.21.851723@Aint.Valid...
> On Fri, 27 Jan 2006 00:52:31 +0000, d wrote:
>
>> "Michael Winter" <m.winter@blueyonder.co.uk> wrote in message
>> news:D2aCf.9698$wl.2@text.news.blueyonder.co.uk...
>>> On 26/01/2006 17:43, d wrote:
>>>
>>>> Where to begin.
>>>
>>> It would be nice if you started by not top-posting, but I don't think
>>> that's a requirement of this particular group.
>>>
>>>> I don't want .php files on the end of my files, because when the user
>>>> gets them, they don't have any PHP in them.
>>>
>>> Given that the average user isn't really aware of what HTML is, I
>>> wouldn't
>>> say that that was much of a reason to reconfigure a server in the way
>>> you'd like.
>>
>> I don't code sites for just your average user. If you're selling your
>> company, or indeed a product, to people who know, then things like this
>> speak very highly of the attention you pay to your work. It's like
>> making a
>> great watch, then using bits of old band-aids for a strap.
> Don't know who you code for, but quality begins with w3c, not
> url extensions.
>>
>>>> That .PHP is there for my benefit, not theirs, which is unwanted.
> No, the php extension is there for the web servers benefit. No matter what
> you say, parsing every page for the potential existence of code, and then
> working out what it is *is* expensive.

My tests show that it is very very cheap, actually. Though please tell me
what tests you would like performed, and I will do that.

> The programmers who generated apache decided on this method. They *do*
> know more than you about serving web pages. I guarantee it.
>>>
>>> If you were really concerned about this, wouldn't the best solution be
>>> to remove 'extensions' from URLs entirely? If you want to relieve the
>>> user of this 'burden', then hiding the mechanics should be the ultimate
>>> goal.
>>
>> Now you have it :) I moved from the .html-only set-up to my own site
>> engine, which does indeed do away with extensions altogether.
> Non-apache web servers are off-topic for this group.

A site engine is not a web server. A site engine is a website framework
that sits on a web server of your choice. And why is it off-topic? I don't
see apache anywhere in the newsgroup name.

>>
>>> [snip]
>>>
>>>> My tests have shown, to me at least, that the performance hit is a
>>>> myth.
>>>
>>> Perhaps, but you haven't actually stated what these tests specifically
>>> entailed so no-one else can perform them and reproduce your results, or
>>> even judge how relevant the tests are to their own circumstances.
>>
>> I did. I hit two identical servers, one set to parse html via php, and
>> one not, repeatedly with sets of 150 requests (not just once, but many
>> times in a row), and recorded the times. The times fluctuated between
>> the html-parsing server being quicker, and the non-html-parsing server
>> being quicker.
> 150, wow! Lets try actually loading the server, eh? Were the requests
> sequential or parallel? How about a real-world test - a couple of thousand
> page hits per second should do as a start.

Then that's what I'll do. Finally someone has come up with their own
criteria :) Thanks very much.

>>>> [...] It's a more than reasonable trade-off for having a decent site,
>>>> with tidy URLs.
> Where is this site???
>>>
>>> A decent site is determined by many things, but URLs have a relatively
>>> low priority (usability and content clearly come first). Length and the
>>> extent to which they can be remembered and transcribed are the most
>>> important factors and 'extensions' don't impact any of these
>>> significantly at all.
>>
>> But once you have code great HTML, great CSS, great PHP, and you server
>> is quick, smooth and working well, it doesn't make sense to just stop
>> making your site better. I won't stop until my site is as perfect as
>> possible. My site engine uses ONLY human-readable urls. No digits, no
>> ridiculous query strings (in fact no query strings at all), and all can
>> be interpreted and even re-written by the user if they want.
> No cookies, no session variables? I don't get why you think that a markup
> language designed to be read by a machine should be pretty - in fact for
> it to be as efficient as possible it should be as small as possible. So
> that's on a single line with no indentation.

Indeed. Did I say the code was human-readable? nope. Just the URLs.

>>
>>> [snip]
>>>
>>> Mike
>>
>> dave
>>
>>> --
>>> Michael Winter
>>> Prefix subject with [News] before replying by e-mail.
>
> Your presumptions are all wrong. You code for w3c first, then search
> engines second.
>
> And you do all you can to protect your server.

That goes without saying.

> Steve

[Back to original message]