|
|
Posted by mac on 08/01/07 21:31
On Jul 31, 12:23 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Michael Fesser wrote:
> > .oO(Jerry Stuckle)
>
> >> That's your opinion. But there are other, more efficient ways to do it.
>
> >> And if what you say is true, why don't Apache and PHP recommend it?
> >> They don't, though.
>
> > They don't say "don't do that" either.
>
> No, they tell you WHAT TO DO - not WHAT NOT TO DO.
>
> >> And they know best.
>
> > Not always. There are also some default options in the Apache config,
> > which are at least questionable. But that's another story.
>
> In your opinion.
I would say Apache and PHP have been around long enough to know what
is efficient and what is inefficient. They don't tell you "don't do
that" because they could care less how inefficiently you wish to run
your server. They could probably come up with thousands of things
"not to do", but why would they "waste their resources" with that?
Instead, they tell you the most efficient way, "what to do".
>
> >>> There are, I already gave some. One reason was to have proper URLs
> >>> without a .php suffix. Of course there are other ways to do that, but
> >>> passing all pages through PHP is one way to achieve that goal and is
> >>> quite easy to setup. This _is_ a reason.
> >> No, you haven't given any good reasons for parsing all files as PHP.
> >> What you have done is given the most inefficient way possible to achieve
> >> that goal.
>
> > That's your opinion.
>
> No, it's a fact.
A sacrifice of ease over efficiency is perfectly acceptable on a test
machine, that way when you push it to production, you know how slowly
it "won't" run. So yea, I guess that _is_ a reason...not valid.
>
> >> Oh, but there are - a huge number of other things going on even before
> >> the parser gets involved - like loading the parser in that process or
> >> thread, setting up the PHP environment, parsing the URL, and so on.
>
> > Some of them can be avoided if PHP is installed as a module, some other
> > work is required for SSI as well.
>
> No, even set up as a module all of the above has to be done. And the
> only thing done with SSI is to load the module. It doesn't set up a
> special environment, parse a url, or any of the rest of that.
>
> >> Parsing files for PHP unnecessarily is a waste of a lot of resources.
>
> > So are images in a DB, but we're moving in circles. I don't want to
> > waste any more of my own resources with that. You have your opinion,
> > I have mine. As usual.
>
> Completely off-topic and unrelated to this discussion.
You got it, Jerry. Though I know little about the PHP interpreter, I
know completely that passing every page through the interpreter is
inefficient. How do I know that? It's pretty black and white
really. Have the web server set up to load the SSI module, or, as you
said, have php load up, parse the url, interpret the page and send to
web server...hmm...sounds like a simpler step to me. No brainer.
Images in a database have multiple purposes...not simply retrieval.
To store images in a db for simple retrieval *would* be a waste of
resources. However, since it there can also be a procedure to
manipulate that image, store information along *with* that image, AND
to shrink the SIZE of that image; I'd say it doesn't compare nor
relate to this conversation.
>
> As I said - there are much more efficient ways to get the same result.
> But you ignore that.
>
> > EOD for me
> > Micha
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================
Just my two cents, here, gentlemen. I just can't stand to see
somebody defend a topic they seem to know very little or nothing
about...just enough to get themselves into a tight situation and then
bail when they fail to "win" the debate. So good job, Jerry, master
of the ring. Let me know when you get into another _heated_
debate...I'd love to spectate! :)
Navigation:
[Reply to this message]
|