|
|
Posted by Steve on 01/27/06 05:17
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.
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.
>
>
>> [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.
>
>>> [...] 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.
>
>> [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.
Steve
Navigation:
[Reply to this message]
|