PHP-Yes, HTML-No --- Why?

[d]

Re: PHP-Yes, HTML-No --- Why?

"Steve" <ThisOne@Aint.V alid> wrote in message
news:pan.2006.0 1.27.03.17.21.8 51723@Aint.Vali d...[color=blue]
> On Fri, 27 Jan 2006 00:52:31 +0000, d wrote:
>[color=green]
>> "Michael Winter" <m.winter@bluey onder.co.uk> wrote in message
>> news:D2aCf.9698 $wl.2@text.news .blueyonder.co. uk...[color=darkred]
>>> 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.[/color]
>>
>> 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.[/color]
> Don't know who you code for, but quality begins with w3c, not
> url extensions.[color=green]
>>[color=darkred]
>>>> That .PHP is there for my benefit, not theirs, which is unwanted.[/color][/color]
> 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.[/color]

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.
[color=blue]
> The programmers who generated apache decided on this method. They *do*
> know more than you about serving web pages. I guarantee it.[color=green][color=darkred]
>>>
>>> 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.[/color]
>>
>> 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.[/color]
> Non-apache web servers are off-topic for this group.[/color]

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.
[color=blue][color=green]
>>[color=darkred]
>>> [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.[/color]
>>
>> 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.[/color]
> 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.[/color]

Then that's what I'll do. Finally someone has come up with their own
criteria :) Thanks very much.
[color=blue][color=green][color=darkred]
>>>> [...] It's a more than reasonable trade-off for having a decent site,
>>>> with tidy URLs.[/color][/color]
> Where is this site???[color=green][color=darkred]
>>>
>>> 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.[/color]
>>
>> 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.[/color]
> 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.[/color]

Indeed. Did I say the code was human-readable? nope. Just the URLs.
[color=blue][color=green]
>>[color=darkred]
>>> [snip]
>>>
>>> Mike[/color]
>>
>> dave
>>[color=darkred]
>>> --
>>> Michael Winter
>>> Prefix subject with [News] before replying by e-mail.[/color][/color]
>
> Your presumptions are all wrong. You code for w3c first, then search
> engines second.
>
> And you do all you can to protect your server.[/color]

That goes without saying.
[color=blue]
> Steve[/color]

[d]

Re: PHP-Yes, HTML-No --- Why?

"Geoff Berrow" <blthecat@ckdog .co.uk> wrote in message
news:l0kjt1101s blg2hfv87s5bnb3 gkutraq5o@4ax.c om...[color=blue]
>
> Message-ID: <j9eCf.9903$wl. 8490@text.news. blueyonder.co.u k> from d
> contained the following:
>[color=green]
>>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.[/color]
>
> I think you are being massively oversensitive.
>
> British telecom is the major telecommunicati ons provider in the UK When
> I go to pay my bill I get this:
>
> https://www2.bt.com/youraccount?coex...cefkdffndfkn.0[/color]

Which is nasty-looking. They also have shitty phone support - should no-one
strive to be better?
[color=blue]
> When I go to pay my gas bill:
>
> http://www.house.co.uk/cgi-bin/house...ergy_acq_nov05
>
> Electricity is a bit more friendly
>
> http://www.npower.com/At_home/Custom...ll_online.aspx
>
> No.html anywhere.
>
> Now tell me, exactly what is worrying you about .php ?[/color]

Just because they don't do it doesn't mean it shouldn't be done :)
[color=blue]
> --
> Geoff Berrow (put thecat out to email)
> It's only Usenet, no one dies.
> My opinions, not the committee's, mine.
> Simple RFDs http://www.ckdog.co.uk/rfdmaker/[/color]

[d]

Re: PHP-Yes, HTML-No --- Why?

"Andrew DeFaria" <Andrew@DeFaria .com> wrote in message news:43d9daee$0 $95950$742ec2ed @news.sonic.net ...
d wrote:

I don't code sites for just your average user.
So then, by definition, you are the exception to the rule. No big deal really. But you shouldn't expect people to agree with you.

I don't. I never said I do.

If you're selling your company, or indeed a product, to people who know,
People who know and people who care are two entirely different worlds.

When they pay your bills, they are exactly the same :)

then things like this speak very highly of the attention you pay to your work.
Yeah it's says your a pinhead, hellbent on spending many resources for foolish consistencies.

"many resources" is a bit far-fetched. Saving documents as .html instead of .php is not "many resources".

It's like making a great watch, then using bits of old band-aids for a strap.

Hardly. It's more like making a great watch and then adorning it on the inside where nobody can really see it.

No, as people do see URLs. That's the essence of a website. People use them for marketing, put them on advers, print them on t-shirts, use them for tracking, etc.

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.

Where might that be?

umm on the web server? Where do you think? Under the kitchen sink? :)

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.
You've neglected to define what "better" is. All you've said is that the URLs should end in .html. I've never heard a single person say to me "Yeah great site! But their URLs don't end in .html so I'm never going back" and I don't think you have every heard that either!

Better = as you want it. Making concessions on presentation due to perceived limitations of your setup is not "better".

I won't stop until my site is as perfect as possible.
A sure sign of a neurotic person!
Or someone bidding for a contract. Arguably they are the same ;)
--
I have six locks on my door all in a row. When I go out, I lock every other one. I figure no matter how long somebody stands there picking the locks, they are always locking three.

[d]

Re: PHP-Yes, HTML-No --- Why?

"Andrew DeFaria" <Andrew@DeFaria .com> wrote in message news:43d9e0ca$0 $96004$742ec2ed @news.sonic.net ...
d wrote:
Here's a hint - they couldn't give a rat's ass what the extension is.
Not everyone, but some people.
No most people! Take this thread as an example. You are arguing to have .html at the end of every URL even if the file contains PHP or another scripting language. At least 4 people in this thread alone disagree with you. That would be 80% agree with me and 20% agree with you (with you, the only person mind you, in your camp). By that very figure you are in the minority and I'd venture to guess the the number of people who really, really care about such trivial things such as yourself is probably closer to .1% in the real population.

Now who's talking about ridiculously small sample sizes. This is not a popularity contest. I am not so insecure as to require pats on the back from my peers to be confident in what I'm doing. I can look through my CV to see that I'm doing well. And I would hardly assume a usenet group dedicated to coding PHP as representative of the public at large :)

And if you cater for those people, it suddenly gets very important.
Yes to all of those neurotic people I supposed...

No, as I said - if they pay your bills, you don't leave anything to chance.

FTP requests are not HTTP.
So what? Should all files that are ftp'ed have a .ftp extension?!?
We are talking about web servers, not FTP servers. I thought you would understand that.

If your logic were to be taken consistently then would it not likewise extend to to ftp? Come on Mr. Consistency!

When your browser gets files from ftp://, it's not a web browser any more but an FTP client.
No it's still a web browser, doing ftp protocol.
FTP is not part of the web. It's part of the internet, but not part of the web. Again, I thought you would understand that.

I do understand that - but my browser also understands ftp protocols as well as many other types (gopher (remember gopher), mailto (a pseudo thing at best but still - it's in there), telnet, ftp and others. There all part of the RFCs. Indeed the whole thing about the browser and the World Wide Web was to tie these desperate, different and confusing to the layperson protocols in a point and click interface. That's why URL's were conceived and conceived to handle not just http, but other protocol types. Just because http is the most popular does not mean it's the only part of the web. Indeed that's one of the very reasons why the original (well as of 3.0 and greater) Netscape included a mail reader, news readers, etc.

Yes, but your WEB browser ceases to be a WEB browser when it leaves the WEB - see?

I said pissing match, not pissing.
A pissing match starts when somebody starts pissing junk.
Fantastic. Really great work.
Hey I can piss with the best of them - or, in this case, the worse of them... :-)

I never said the server should parse MP3 files or whatever, as I'm not generating them dynamically.
What does it matter if you are doing it dynamically or not?
Apparently it does to you - as you want your dynamically-generated content to be called .php, as that's how it should be "by design".
I see no reason to change the fact that this web page came from a file that had a .php extension. Indeed I see it as useful in that it is a sign that the content is dynamic and/or generated as opposed to static. By renaming things to html you lose that distinction, which can be helpful at times.

No, site design, project management, and good designers make up for that.

The point about MP3 files is that if you configure your web server to treat every file as potentially having dynamic content and that it should search through the entire file looking to determine exactly which language might be in use in the file and hand it off to the appropriate parser, interpreter or module then you are gonna have to contend with the fact that occasionally (and on some sites much more than occasionally) you're gonna be charging the web server with reading and parsing potentially huge files - all in the name of a foolish consistency.

I didn't say EVERY file. I said .HTML files. Please tell me where I said it should parse every single file. Please do.
It's not a fetish. It's called presentation.

No it's called necrosis! As for presentation what's important is CONTENT stupid!

When you start writing sites for big clients with big requests and big ideas, that assertion will seem as foolish to you as it does to me.

Just because you can't care less doesn't mean those visiting your site don't.

As I said, I've never, ever had anybody say "Great site but I won't use it until they have URL's that end in .html".

My tests have shown, to me at least, that the performance hit is a myth.
For 150 files, perhaps.
Repeatedly, about 50 times.
Yes, right, only after 3 of use pointed out that 150 files are not statistically significant. Nor is 50 times of 150 files. A lot depends on the sizes of the files, the configuration of the server, how much memory is currently being used, how busy it is, etc. Again, your "test" is not statistically significant. Come back to use after you've figured out how to do thousands of hits a minute and run it for a few hours.
7500 requests to each server, which are housed on the same box and are configured identically apart from how PHP is used, even using the same document root, gives a good indication of performance. You won't learn anything in hours of testing you didn't know after minutes, it's just that the absolute difference in the numbers will be larger.

It's not wasteful.
How could it not be? You do understand how computers work don't you? You do understand that extra processing is indeed happening. You do understand that under large numbers of accesses such small differences in processing time add up don't you?!?
I also know how the PHP module works. I can see that the extra processing is negligable compared to other factors affecting the server. My tests have shown that.
No, they haven't.

They've strongly indicated that. I've yet to see anything that says otherwise.

If what you say is true, my html test server should have repeatedly out-performed the html-parsing one. It didn't.
When you run such puny tests it's extremely hard to say. You are also not in a controlled environment in any way, shape or form. A discrepancy such as you claim can easily be explained but a small demand on the server from anything from cron to a swap.

Please tell me about how you know about my setup :) I'm intrigued to know ;)

You wouldn't want your design sloppy,
I don't find it sloppy. Indeed I find it very logical.
Logical from the web server's perspective, not the user's.

As a user I find your answer odd. I also find it logical from a user's perspective. I would find it illogical for it to say .html when I know that .html represents static HTML yet I got a dynamic page!

HTML represents the content, not how the file was generated.

As websites are coded to make the user happy, not the webserver, that's a pretty poor excuse.

Yes you are using pretty poor excuses! Stop that!

Hardly.

so why your URLs? The site is a whole - asking someone to ignore the mess in the address bar because "it's just the way the web server works" is a bit silly. It's supposed to work for you, not the other way round :)
Again, nobody cares about what characters are in the URL. If they did they'd start screaming about the silly http:'s and the &parm=<long assed string of junk characters> and the like. The .php or .html at the end is one of the least things to be concerned about!
Just saying "but nobody cares" doesn't make them not care.
3 other people have repeated what I said - Nobody cares. You are the sole person saying that people care. That's a 80 to 20% against (guess who?) - YOU.

Oh shit! 3 people! From a newsgroup filled with some really abysmal coders. Wow. What real peer review that is. The Creme de la creme of development, surely.

And as for the query string - I agree with you. I don't use query strings.
Your sites then must not have very much functionality or utility - but their URLs look nice! ;-)
Tell that to the clients who pay lots of money for them. They seem rather happy with them.



Just because it's least concerning doesn't make it not concerning at all. It's like making a painting and putting it in a crappy frame.

No, again, it's like making a painting then scribbling on the back of the painting that nobody sees nor cares about.

But people do see the URLs. The URLs are used all the time.

--
If you take an Oriental person and spin him around several times, does he become disoriented?

[Andrew DeFaria]

Re: PHP-Yes, HTML-No --- Why?

d wrote:[color=blue]
> "
>
> Nor have I seen any qualification of why it's bad (aside from the
> fact that you, the one person in this thread, don't like it).
>
>
> Because the files, when downloaded, are called .php and have
> absolutely no php in them :)[/color]
Wonderful! And why is that bad?!? (All you do if evade this question)[color=blue]
>[color=green]
>> I mean, the file doesn't contain php when the client gets it,
>> so why should it be named .php?[/color]
> Simple, because that was the filename that was requested to be
> fetched by the web server!
>
> But the extension doesn't match the contents of the file.[/color]
So fucking what!?![color=blue]
> The fact it's the extension of the file is no reason for the file to
> have that extension :) Circular logic is rarely a good reason for
> anything :)[/color]
Then why do you use it so much?[color=blue]
>[color=green][color=darkred]
>>> Surely a dynamic web server should appear exactly the same
>>> as a static one - all files that contain HTML when viewed
>>> should be called .html.[/color]
>> Again, why? Who cares (besides you)?
>>
>> Because the server is serving up HTML, not PHP.[/color]
> So fucking what! (Man you are dense!)
>
> Because the files contain html, not php.[/color]
Many you are dense. Again so fucking what![color=blue]
> That's pretty obvious.[/color]
Yes, but what's not obvious is why it's a problem. I feel like I'm
arguing with an 8 year old where I ask why and they say because - over
and over again.[color=blue]
> You may not think that's anything big,[/color]
Correctly - I don't think it's any problem whatsoever![color=blue]
> but presentation-wise it is big.[/color]
Only in your little world. Most people pay attention to the web page not
the address.[color=blue]
> If you request a .jpg, you expect to get a jpeg.[/color]
Hmmm... ah, let's analyze this a little bit. I request a web page with a
URL with .html, I see an image. Many that's screwed up. I expected HTML,
I got an image! That's fucked.[color=blue]
> If you request a .mpeg, you expect a movie. If you request a .mpeg
> and get a csv, that's not really cool.[/color]
If I requested a .cvs what exactly would I see?[color=blue]
>[color=green]
>> Let's us know when you're done writing your great web server!
>> :-(
>>
>> I don't have to. It's called apache, and it does the trick
>> perfectly.[/color]
> I guess you're not done yet...
>
>
> What? :)[/color]
Never mind - if you don't understand that you'll never be done.[color=blue]
>
> You're proposing to rename .php files to .html files. I guess
> we're gonna rename .asp and .jsp files to that too. Hmmm... Maybe
> .cfm files (Cold Fusion?) and .do (I've seen those too). Gee that
> web server's gonna have much more work to do sorting that out.
>
> And you're forgetting - PHP files can also be just PHP script
> designed to run without a web server. So now PHP developers are
> gonna have to name some files .html and others .php - nice
> consistency there Mr. Consistency!
>
> If they're not on a webserver, then they can be called .php.[/color]
What kind of stupid assed statement is that. Web servers are first and
foremost machines too. As machines it's quite possible that development
of php scripts as well as running of php script would happen. You make
no sense, are all over the map and an idiot![color=blue]
> In fact, when I put my php files not on a webserver, say as scripts to
> be run from the windows command prompt, I call them .xphp,[/color]
Just to confuse everybody else who uses .php. A very wise move there,
very wise.[color=blue]
> as I have a handler set up to automatically pass those files to the
> php executable when they're run, much like a .bat file and cmd.exe.[/color]
Figures that you'd be using Windows...[color=blue]
> We're talking about consistency in the web server here, from the
> client's perspective. You seem to forget the website is there for the
> client ;)[/color]
Right, whatever. Anybody ever tell you you make very little sense?[color=blue]
>
> If a web server has to parse through a file and look for different
> tokens to denote which type of file it might possibly be it will
> be more complex than the current typing system.
>
> I didn't say that.[/color]
No you didn't - I did! Don't you understand how quoting works?[color=blue]
> There are many ways to determine what's in a file, not just the
> contents, and not just the extension. It's really not difficult, not
> complex, and not uncommon.[/color]
Such as?[color=blue]
>
> Which means we can ignore it as it's pretty much meaningless.
> Again, nobody cares about the damn URL extension here but you.
> Every other poster in this thread disagrees with you. You are the
> exception to the rule, the odd man out. By now you should be used
> to the fact that people just do not agree with your opinion here
> and do not value this foolish aesthetic distinction that you draw
> that really hold very little utility. By the very definition and
> example of this thread any reasonable person would deduce that in
> general most people don't care. But bang your head against the
> wall if you must and jump up and down stomping your feet if you
> want - it's actually quite comical. You configure your web servers
> for your URL consistency and pat yourself on the back. Whatever
> floats your boat. I have more important things to waste my time with!
>
> If you think aesthetics are meaningless, then your websites must look
> like shit.[/color]
No I think that your silly notion that anybody cares about the
aesthetics of the URL is meaningless. So far everybody else in this
thread agrees with me. Now where does that put *YOU*?[color=blue]
> Just because no-one else cares about the extensions here, doesn't mean
> that no-one does.[/color]
Fine, point me to some testimonials from people, aside from yourself,
that do care about that?[color=blue]
> I can't help it if you aren't as exacting as some people.[/color]
I guess I can't help it if your a neurotic fool with obsessive
compulsive behavior WRT URLs... I guess.[color=blue]
> If you can't be bothered to address every aspect of your website,
> then why bother creating one?[/color]
For it's utility. Listen, here's a clue to the clueless neurotics out
there such as yourself. Nothing is ever 100% complete nor bug free nor
completed when it comes to computers and the web. Striving to get as
close to 100% as possible, while some think is an honorable goal or
intention, is surefire death for any business man and anybody else who
is reasonable. Indeed your statement essentially says if you can't
achieve perfection then don't even try! Ridiculous! This is a statement
of somebody who needs professional help - and I hope you find that soon.[color=blue]
> So you don't put line breaks in your HTML or CSS, as that's extra
> complexity and processing for very little gain.[/color]
Huh? That's no extra complexity or processing. line breaks do not
require processing - at least they don't require loading a whole
compiler/syntactic checker/interpreter into memory and increase resource
usage.[color=blue]
> And as I demonstrated, the extra processing of parsing .html as php is
> absolutely minimal, to the point where tests can't even determine
> which one is quicker, as there are many, many other variables that
> have a much larger impact on performance than that.[/color]
You're "demonstrat ion" says nothing of the sort.[color=blue]
>[color=green][color=darkred]
>>> you probably shouldn't be anywhere near a computer in case
>>> you look at it funny and choke yourself to death.[/color]
>> And you're the one getting bent out of shape because a file
>> says .php instead of .html. Who's confused here? (Hint: You are!)
>>
>> How is that being confused?? I just want files named to reflect
>> what's in them. You wouldn't want your html files called .jpg,
>> would you?
>>[color=darkred]
>>> And as I said earlier, it doesn't stop anyone from using
>>> multiple technologies at once,[/color]
>> Yes but it adds unnecessary complications and processing time
>> based on a whim that only you have!
>>
>> No complications what so ever.[/color]
> What so ever? Are you sure? When's your web server gonna be
> complete there bud?
>
> You keep banging on about that. I don't need to write a webserver.[/color]
Correction - you couldn't if you tried.[color=blue]
> As I keep saying, Apache was designed to do just this. The PHP module
> for apache was designed to do just this. Just because you can't see
> how technology can be used doesn't automatically dismiss those who
> can. There are no complications. If you think it's complicated to
> have php code in files called .html, then you really do need help.[/color]
It's not that it's complicated - it's not recommended. Now why is that?[color=blue]
>[color=green]
>> The extra processing time, as I have demonstrated is nothing.[/color]
> You're demonstration is non conclusive. Sample size was too small.
>
> 150 documents at a time, repeated nearly 50 times? Too small?[/color]
Yes it is.[color=blue]
> Then please - tell me what you want tested, and I'll test it, and give
> you the figures.[/color]
I did already - go look it up.[color=blue]
>[color=green]
>> My tests showed that sometimes it's even quicker to do it this
>> way, which means that there are other factors that play a much
>> bigger part in performance, much more than parsing .html files.[/color]
> Or perhaps your machine was busy servicing others.
>
> It wasn't. I conducted the test as accurately as humanly possible,
> which of course meant no other sites were busy handling requests.[/color]
Right, and no other processes were going on - you closed all the icons
on your desktop. Trouble is lots of other stuff was running.[color=blue]
>[color=green][color=darkred]
>>> and if a web server struggles because it has to check html
>>> files for php when there necessarily isn't any,[/color]
>> It's not a struggle - it's a waste of time! Do you understand
>> the definition of the word efficient?!?
>>
>> If you think presentation is a waste of time,[/color]
> Presentation is in the page itself - not its address!
>
> So a great house on a shitty street is just as good as a great house
> on a great street?[/color]
A street is at least as large as (physically) if not larger in area than
any house. A URL is but 1% of the area of the browser window and it's a
1% that people by and large do not look at or at least do not look at in
terms of prettiness nor value or meaning. To re-use your analogy more
properly it's like a great house with a busted garage door handle is
roughly the same as a great house with a great garage door handle. IOW
if I saw that great house with the busted garage door handle I know that
I would not walk away from the deal, nor would 99.9% of anybody else -
but you would apparently![color=blue]
>[color=green]
>> then fine - I can't convince you otherwise.[/color]
> Nor the other 3 people here. You're batting 1000% - -1000%!
>
> Now who's talking about small sample sizes :)[/color]
Unlike web pages and web servers which are computers and documents that
typically are served hundreds if not thousands of times each minute,
news articles rarely have hundreds or thousands of articles posted to a
thread ever minute. So no, my sample size is by no means small.[color=blue]
>[color=green]
>> Efficiency doesn't necessarily mean you end up with the best
>> product.[/color]
> Who's talking about products. We're talking about Apache. That
> ain't even sold!
>
> The website is a product. You sure don't sound like you know much
> about commercial web development.[/color]
Nor do you.[color=blue]
>[color=green][color=darkred]
>>> then it's not going to be very good at running any complex
>>> php, as that requires a LOT more work then just checking for
>>> "<?php" in a file.[/color]
>> Again, it's unnecessary work. You can't seem to understand
>> that simple concept.
>>
>> I've demonstrated the "unnecessar y work" is absolutely,
>> positively nothing.[/color]
> No you haven't.
>
> I have.[/color]
Gosh, what an 8 year old mentality. "Yes I have! Yes I have! Yes I
have!". Get back to me after your tantrum is done and with some real data.[color=blue]
>[color=green][color=darkred]
>>> Just because it's the "done thing" doesn't automatically
>>> make it the best thing.[/color]
>> Again, in this case it does. If not then make your own web
>> server and see who else in the planet is interested in such
>> "technology ". But don't quite your day gig!
>>
>> Can you qualify these assertions.[/color]
> I don't need too. You are the one making the claim. And you are
> attempting to make it with a very unscientific nor statistically
> significant sample. Look at it this way. I would venture to get
> that the guys over at Apache know a hell of a lot more about
> writing web server software than you. When you are writing such
> software you make trade offs and decisions. They *decided* to make
> this trade off for the sake of efficiency. Now why do you think
> they did that? Because it's true. Or would you have us believe
> your tiny test of 150 files, even done 50 times, overrides the
> experience of these experts? IOW why do you think they set it up
> this way?
>
> Of course you need to. You can't just make an assertion then expect
> others to believe you without proving anything.[/color]
Exactly. You made the assertion. You have yet to provide proof.[color=blue]
> Who do you think you are? The church? :)[/color]
Actually I'm atheist.[color=blue]
> Apache didn't decide to make the trade-off.[/color]
Yes they did.[color=blue]
> It's not hard-wired in apache.[/color]
Right, it's allowed, but not configured that way by default and
discouraged. That pretty much says it all. Hell, even server side
includes (a process much less taxing than PHP), another allowed
configuration and built in, is turned off by default and likewise
discouraged. Again, that says much.[color=blue]
> You just put ".html" after ".php" on the addhandler line. You really
> don't understand this, do you?[/color]
Yes, however you keep missing the point or dancing around it.[color=blue]
>[color=green]
>> I've done tests, and I've seen that the performance hit is nothing.[/color]
> Tell ya what, package up your "test" and ship them over to the
> folks at Apache along with a note saying "Why did you guys
> separate .html files and .php files. Surely not for efficiency or
> complexity's sake. Look at these numbers I have here...". After
> they get off the floor from rolling around in laughter I'm sure
> they'll getting back to you! ;-)
>
>
> APACHE DON'T SEPERATE THE FILES! Jesus, man. Apache provide the
> mechanism for electing which extensions are parsed by which handlers.
> They don't write PHP, or even bundle it with their servers, so why on
> earth is it their decision to seperate the two? The two aren't even
> seperated, for crying out loud. Just because it shows in the example
> in the php manual that they only put .php doesn't mean that's how they
> only intended it to be used. If you only stick to the examples on the
> php website, your site will be incredibly basic, poorly coded, and
> slow as all hell.[/color]
What's a matter, scared what the answer would be?[color=blue]
>[color=green]
>> I don't have to make my own web server.[/color]
> You probably couldn't if you tried, which was my point - you don't
> know the half of the story as to why this technical trade off was
> implemented. Sure Apache allows you to configure it in the way you
> want it but they warn direly not to do that because things will be
> slow. You think they say that on a whim? Hey, perhaps they have a
> 151 file test! LOL!
>
> Can you show me where they warn to not do that?[/color]
Why? You wouldn't follow their advice anyway.[color=blue]
>[color=green]
>> Apache was built to do just these things. The reason PHP moved
>> from CGI to a native apache module was for exactly this kind of
>> thing. If you don't understand the technology, then perhaps you
>> shouldn't quit your day job :)[/color]
> I understand it far better than you as you continually see fit to
> show the world. PHP was moved into CGI because PHP was designed to
> be part of an otherwise HTML file with the PHP intermixed. As such
> the web server had to handle the reading and rendering of that
> HTML. It was also moved in there for efficiency reasons instead of
> having to start a separate PHP process, much like mod_perl.
>
> I'm not talking about CGI. I've never been talking about CGI here.
> I'm talking about the php apache module.[/color]
Huh?[color=blue]
>[color=green][color=darkred]
>>> If you don't want to take pride in your work and have messy
>>> URLs with weird extensions that don't match the content and
>>> query strings unreadable to humans stretching from here to
>>> the moon, then be my guest.[/color]
>> I measure my work by the quality of the content of the page
>> itself - not it's URL. To me, and everybody else in the world
>> except apparently you, I don't find .php as a weird extension
>> (perhaps because I understand it) nor as any more messier
>> than .html. It's you that have a fetish with that - not I.
>>
>> I measure my work by the user experience.[/color]
> I measure my work by user satisfaction.
>
> Which is directly proportional to user experience.
>[color=green]
>> I don't want any dirty laundry out in the open.[/color]
> What they hell is so dirty about having a URL with a .php in it?!?
>
>
> Because the returned file never has any php in it.
>[color=green]
>> I want complete control over every aesthetic, from the quality of
>> the HTML to the quality of the addressing.[/color]
> i.e. control freak and neurotic personally.
>
>
> No, more like a perfectionist,[/color]
That's what all neurotic people think and say. (BTW Being a
perfectionist is not a good thing either. Newsflash - the world is not
perfect and you will never be either).[color=blue]
> or at least someone with pride in their work who doesn't just accept
> "the done thing" but seeks to find better ways of doing things.[/color]
Again, nobody else - except you - thinks of it as better.[color=blue]
>[color=green]
>> I find .php a weird extension because the files don't contain a
>> single shred of php when the user gets them.[/color]
> Again, you might not like it but 99.9% of the rest of use don't care.
>
> Clearly you do, as you're still banging on about how supposedly
> ridiculous it is.[/color]
Huh?[color=blue]
>[color=green]
>> And, after all, websites are about the user, not the sysadmin
>> or the developer.[/color]
> Exactly, and if 99.9% of the users don't care and 80% of them have
> no real idea of what a URL even is, then worrying about whether a
> file has a .php or a .html extension is a true sign of neurotic
> behavior. Seek good counsel...
>
> It all depends on who your audience is for your website. If you're
> just writing some blog site or some tiny shop selling CDs, then sure -
> but if you're writing tools and sites for big clients (read:
> international banks, financial institutions, car manufacturers,
> universities, etc.), putting in bids against competing companies, and
> the contract is worth £100,000, then these things do matter.[/color]
Figures you're English (Or Canadian or whatever). Some English people
seem to take a sadistic pleasure at just arguing and being obtuse!
--
The sex was so good that even the neighbors had a cigarette.

[Andrew DeFaria]

Re: PHP-Yes, HTML-No --- Why?

d wrote:[color=blue]
> "Andrew DeFaria" <Andrew@DeFaria .com <mailto:Andrew@ DeFaria.com>>
> wrote in message news:43d9d8c4$0 $95928$742ec2ed @news.sonic.net ..
>
> It's your assertion therefore you are burdened with the prove.
>[/color]
(correction s/prove/proof/)[color=blue]
>
> Tell me what would satisfy you, and I'll test it. You seem rather
> quiet on that, though.[/color]
You're proving once again that you either do not read or do not
comprehend. I mentioned this already.[color=blue]
> How are they meaningless? The sample size was good enough, the tests
> were performed enough times, the setups were identical apart from the
> variablel we were testing (the files served were even the same files
> on both sites). Please tell me how you would test it, and I'll do it
> that way.[/color]
Again I explained this already. I'm not gonna repeat it.[color=blue]
>[color=green]
>> So I see you haven't written code for anything approaching
>> massive sites, if you claim that. Thanks.[/color]
> Yeah, where exactly do you see that?
>
> All your silly questions like "what's a product - apache isn't even
> sold" etc. It really shows you've not been around people who are
> actually selling products to people, which you are in charge of
> developing.[/color]
Needless to say I find your deductive reasoning and usage of "logic"
quite odd. The above is just another example of that.
--
Just for today, I will not sit in my living room all day in my
underwear. Instead, I will move my computer into the bedroom.

[Andrew DeFaria]

Re: PHP-Yes, HTML-No --- Why?

d wrote:[color=blue]
>[color=green]
>> If you're selling your company, or indeed a product, to people
>> who know,[/color]
> People who know and people who care are two entirely different
> worlds.
>
> When they pay your bills, they are exactly the same :)[/color]
It's irrelevant if they are paying your bills or not. The sets of people
who know and people who care are still distinct. I doubt that a single
person has ever been fired, not paid or told to change the URLs in he
web design because they ended in .php.[color=blue]
>[color=green]
>> then things like this speak very highly of the attention you pay
>> to your work.[/color]
> Yeah it's says your a pinhead, hellbent on spending many resources
> for foolish consistencies.
>
> "many resources" is a bit far-fetched. Saving documents as .html
> instead of .php is not "many resources".[/color]
Gosh you still don't seem to grasp the issues here...[color=blue]
>[color=green]
>> It's like making a great watch, then using bits of old band-aids
>> for a strap.[/color]
> Hardly. It's more like making a great watch and then adorning it
> on the inside where nobody can really see it.
>
> No, as people do see URLs. That's the essence of a website.[/color]
My god how moronic can a person be! The essence of a website is the part
below the URL not the URL.[color=blue]
> People use them for marketing, put them on advers, print them on
> t-shirts, use them for tracking, etc.
>[color=green][color=darkred]
>>> 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.[/color]
>> 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.[/color]
> Where might that be?
>
> umm on the web server? Where do you think? Under the kitchen sink? :)[/color]
Now you're being obtuse. Why to I get the sinking feeling that I'm
wrestling a pig in the mud....[color=blue]
>[color=green]
>> 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.[/color]
> You've neglected to define what "better" is. All you've said is
> that the URLs should end in .html. I've never heard a single
> person say to me "Yeah great site! But their URLs don't end in
> .html so I'm never going back" and I don't think you have every
> heard that either!
>
> Better = as you want it.[/color]
Sounds to me that what you really meant is "better = as 'd' wants it".
We (the other 99.9%) want it as .php. Ergo our web sites are already
"better".[color=blue]
> Making concessions on presentation due to perceived limitations of
> your setup is not "better".[/color]
There ya have it. We want .php (*YOU* want .html but nobody else does).
Ergo there is no concession on presentation at all and our web sites are
already "better". Case closed, argument done (Next idiot!).[color=blue]
>[color=green]
>> I won't stop until my site is as perfect as possible.[/color]
> A sure sign of a neurotic person!
>
> Or someone bidding for a contract. Arguably they are the same ;)[/color]
Right... Hope you got your meds....[color=blue]
>
> I have six locks on my door all in a row. When I go out, I lock
> every other one. I figure no matter how long somebody stands there
> picking the locks, they are always locking three.
>[/color]
The above, from one of my randomly selected sigs, is another example of
a neurotic person. You should like him - he's Steve Wright. Bet he
insists on .html too! :-)
--
Some people say "life is short". What?? Life is the longest damn thing
anyone ever does!! What can you do that's longer?

[Andrew DeFaria]

Re: PHP-Yes, HTML-No --- Why?

d wrote:[color=blue]
> "Andrew DeFaria" <Andrew@DeFaria .com <mailto:Andrew@ DeFaria.com>>
> wrote in message news:43d9e0ca$0 $96004$742ec2ed @news.sonic.net ...
>
> d wrote:[color=green]
>>
>> Here's a hint - they couldn't give a rat's ass what the
>> extension is.
>>
>> Not everyone, but some people.[/color]
> No most people! Take this thread as an example. You are arguing to
> have .html at the end of every URL even if the file contains PHP
> or another scripting language. At least 4 people in this thread
> alone disagree with you. That would be 80% agree with me and 20%
> agree with you (with you, the only person mind you, in your camp).
> By that very figure you are in the minority and I'd venture to
> guess the the number of people who really, really care about such
> trivial things such as yourself is probably closer to .1% in the
> real population.
>
> Now who's talking about ridiculously small sample sizes. This is not
> a popularity contest. I am not so insecure as to require pats on the
> back from my peers to be confident in what I'm doing. I can look
> through my CV to see that I'm doing well. And I would hardly assume a
> usenet group dedicated to coding PHP as representative of the public
> at large :)[/color]
Not at all. I've already explained this in another post. Go read that.[color=blue]
>[color=green]
>> And if you cater for those people, it suddenly gets very important.[/color]
> Yes to all of those neurotic people I supposed...
>
> No, as I said - if they pay your bills, you don't leave anything to
> chance.[/color]
I've found it best not to work for or with neurotic people. YMMV.[color=blue]
>
> I do understand that - but my browser also understands ftp
> protocols as well as many other types (gopher (remember gopher),
> mailto (a pseudo thing at best but still - it's in there), telnet,
> ftp and others. There all part of the RFCs. Indeed the whole thing
> about the browser and the World Wide Web was to tie these
> desperate, different and confusing to the layperson protocols in a
> point and click interface. That's why URL's were conceived and
> conceived to handle not just http, but other protocol types. Just
> because http is the most popular does not mean it's the only part
> of the web. Indeed that's one of the very reasons why the original
> (well as of 3.0 and greater) Netscape included a mail reader, news
> readers, etc.
>
> Yes, but your WEB browser ceases to be a WEB browser when it leaves
> the WEB - see?[/color]
The "web" is not just transactions of http protocol. See?[color=blue]
>[color=green]
>> It's not a fetish. It's called presentation.[/color]
> No it's called necrosis! As for presentation what's important is
> *CONTENT* stupid!
>
> When you start writing sites for big clients with big requests and big
> ideas, that assertion will seem as foolish to you as it does to me.[/color]
Not a single other person is on your side WRT to this. You can't see that?[color=blue]
>
> When you run such puny tests it's extremely hard to say. You are
> also not in a controlled environment in any way, shape or form. A
> discrepancy such as you claim can easily be explained but a small
> demand on the server from anything from cron to a swap.
>
> Please tell me about how you know about my setup :) I'm intrigued to
> know ;)[/color]
I don't - which is the whole point. You first came on here saying just
150 files. Now you're upping that number to 7500 and saying 50
iterations. You clearly have a neurotic agenda to promote your opinion.
It's hard to trust your numbers and environmental setup, which appear to
be small to start with. We would need a 3rd party confirming this.[color=blue]
>[color=green][color=darkred]
>>> You wouldn't want your design sloppy,[/color]
>> I don't find it sloppy. Indeed I find it very logical.
>>
>> Logical from the web server's perspective, not the user's.[/color]
> As a user I find your answer odd. I also find it logical from a
> user's perspective. I would find it illogical for it to say .html
> when I know that .html represents static HTML yet I got a dynamic
> page!
>
> HTML represents the content, not how the file was generated.[/color]
No, html files represent static web content - as defined in the RFCs.
For dynamic content, originally, one had to use CGI. Later Perl, PHP,
ASP and other technologies came around. .html files have always
represented static content.[color=blue]
>[color=green]
>> As websites are coded to make the user happy, not the webserver,
>> that's a pretty poor excuse.[/color]
> Yes you are using pretty poor excuses! Stop that!
>
> Hardly.[/color]
Yes, I see you are continuing, and I am tiring of this.[color=blue]
>[color=green][color=darkred]
>>> so why your URLs? The site is a whole - asking someone to
>>> ignore the mess in the address bar because "it's just the
>>> way the web server works" is a bit silly. It's supposed to
>>> work for you, not the other way round :)[/color]
>> Again, nobody cares about what characters are in the URL. If
>> they did they'd start screaming about the silly http:'s and
>> the &parm=<long assed string of junk characters> and the
>> like. The .php or .html at the end is one of the least things
>> to be concerned about!
>>
>> Just saying "but nobody cares" doesn't make them not care.[/color]
> 3 other people have repeated what I said - Nobody cares. You are
> the sole person saying that people care. That's a 80 to 20%
> against (guess who?) - YOU.
>
> Oh shit! 3 people![/color]
As opposed to your just 1 person. Hey, I win! I win![color=blue]
> From a newsgroup filled with some really abysmal coders. Wow. What
> real peer review that is. The Creme de la creme of development, surely.[/color]
Don't negate the fact that you are the only one arguing for this silly
consistency! Even the writers of Apache disagree with you - but hell
what do they know![color=blue]
>[color=green]
>> And as for the query string - I agree with you. I don't use
>> query strings.[/color]
> Your sites then must not have very much functionality or utility -
> but their URLs look nice! ;-)
>
> Tell that to the clients who pay lots of money for them. They seem
> rather happy with them.
>[color=green]
>> Just because it's least concerning doesn't make it not concerning
>> at all. It's like making a painting and putting it in a crappy
>> frame.[/color]
> No, again, it's like making a painting then scribbling on the back
> of the painting that nobody sees nor cares about.
>
> But people do see the URLs. The URLs are used all the time.[/color]
OK, it's like making a painting then scribbling your tiny signature in
the corner - a practice done all the time and guess what? Nobody says
"I'd buy that painting except for that signature in the corner. That
dude has terrible handwriting so I'm not buying". Funny thing is that
you actually buy into such thinking.
--
Ever notice that anyone going slower than you is an idiot, but anyone
going faster is a maniac?

[Michael Winter]

Re: PHP-Yes, HTML-No --- Why?

On 27/01/2006 00:52, d wrote:

[snip]
[color=blue]
> 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.[/color]

Assuming that those 'who know' agree with your particular philosophy. As
evidenced in this thread, not all will and that may lead to a negative
evaluation of your capabilities.

[snip]

[MLW:][color=blue][color=green]
>> If you were really concerned about this, wouldn't the best solution
>> be to remove 'extensions' from URLs entirely? [...] hiding the
>> mechanics should be the ultimate goal.[/color]
>
> Now you have it :)[/color]

It's not exactly a new idea.

[snip]
[color=blue][color=green]
>> [...] you haven't actually stated what these tests specifically
>> entailed [...][/color]
>
> I did.[/color]

You gave a vague description.

[snip]
[color=blue]
> 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.[/color]

And that's fine, laudable. It means nothing as far as 'extensions' in
URLs are concerned, though.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Stan McCann]

Re: PHP-Yes, HTML-No --- Why?

Andrew DeFaria <Andrew@DeFaria .com> wrote in news:43da486e$0 $96016
$742ec2ed@news. sonic.net:
[color=blue]
> Again I explained this already. I'm not gonna repeat it.[/color]

Andrew, give it up and KF the idiot like I did. If he has a server, he
can do as he pleases, otherwise he won't get anywhere with his idiocy.

Everything he has said is totally unfounded and I don't have time for
idiots.

--
Stan McCann "Uncle Pirate" http://stanmccann.us/pirate.html
Webmaster/Computer Center Manager, NMSU at Alamogordo
http://alamo.nmsu.edu/ There are 10 kinds of people.
Those that understand binary and those that don't.

[Steve]

Re: PHP-Yes, HTML-No --- Why?

On Fri, 27 Jan 2006 14:34:20 +0000, d wrote:
[color=blue]
> 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.
>[/color]
Are you writing it in php? if not, how can it be *on* topic?

[Steve]

Re: PHP-Yes, HTML-No --- Why?

Can you stop posting your stuff in html as well, please? This is a
text-based ng.

[Andrew DeFaria]

Re: PHP-Yes, HTML-No --- Why?

Stan McCann wrote:[color=blue]
> Andrew DeFaria <Andrew@DeFaria .com> wrote in news:43da486e$0 $96016
> $742ec2ed@news. sonic.net:[color=green]
>> Again I explained this already. I'm not gonna repeat it.[/color]
> Andrew, give it up and KF the idiot like I did. If he has a server, he
> can do as he pleases, otherwise he won't get anywhere with his idiocy.
>
> Everything he has said is totally unfounded and I don't have time for
> idiots.[/color]
Pretty much my thoughts too. Hey I tried (I don't know why).

Plonk - By d, Dave, whatever...

[Andrew DeFaria]

Re: PHP-Yes, HTML-No --- Why?

Steve wrote:[color=blue]
> Can you stop posting your stuff in html as well, please? This is a
> text-based ng.[/color]
I will respectfully answer - No. There. Now you know.

[John Dunlop]

|OT| URL suffixes

d:
[color=blue]
> I mean as in you are showing the world what technology you're using :)[/color]

Nothing wrong with that, in itself.
[color=blue]
> The pages are spitting out HTML, and so logically should have a .html extension
> when the browser sees them[/color]

"Logic" aside, why *should* URLs have .html suffixes? Why *should*
they have .php suffixes? What exactly does this hypothetical URL point
to?

--
Seoc