NYCPHP Meetup

[David Krings]

Elliotte Harold wrote:
> David Krings wrote:
>> Elliotte Harold wrote:
>>> Edward Potter wrote:
>>>> hmmmm, I have never found this to be a problem.  Using includes, you
>>>> can pull in .php code from anywhere, even pages with a .php extension
>>>> may be 99.99% html, with a  just a single include('foo.php') in it.
>>>> Keeps things super streamlined, and your pages are very readable.
>>>>
>>>
>>> You've got it backwards. I want one script to service many URLs, not 
>>> many scripts to service one URL.
>>>
>>
>> And that is exactly how Edward described it. You include the one 
>> script into the many URLs you want to make use of the script.
>> I guess that isn't what you are after, it just reads that way.
> 
> What you are proposing is not one script to service N URLs. It is N+1 
> scripts to service N URLs. It is still necessary to create N separate 
> loader scripts and place them at the right locations. That doesn't 
> scale, and it's an extraordinary waste of resources when a small 
> percentage of the possible URLs will ever be reached.
> 

I sincerely apologize for helping out. I am convinced that my proposal 
would be a suitable solution (you need one script, not more), but 
apparently confusion and misunderstanding takes precedence. If I could 
I'd eradicate my posts to save you from the disgust that I must have 
generated. In any case, I am deeply sorry to have caused you discomfort.

> Overall, though, I suspect all parties (Apache, PHP, Tomcat, Rails. etc.) are still too mired in circa-1994 models of web servers serving file systems. For example, once you map /foo to a servlet you can't then map /foo/bar to something else.

Well, then use IIS and ASP if that is a better solution. As you pointed 
out, these are "circa-1994" models that apparently work very well in 
2007. So much so that almost 2/3 of all internet sites use exactly this 
technology. Those folks must all be idiots for using something that so 
obviously doesn't work! There isn't much technology around that was 
created in the 90s and that still works well for today's needs. I don't 
see the big deal if a web server mirrors a file system structure, the 
problem is on how to get to the desired file - which can be done with an 
arbiter script that gets hit on each access and then redirects to the 
desired location.
Since the server just has to know what to serve up it will be quite easy 
to structure the site based on unique IDs and use a database table to 
retrieve the corresponding paths.
Calling mysite.gov/1234 directs to mysite.gov/foo/bar/index.php and
calling mysite.gov/4321 directs to mysite.gov/bar/foo/index.php. Of 
course, you need to add that information to a table or a simple ini file 
if no db is available. With a table you got one db connection, one 
select query, a few lines error output in case the resource doesn't 
exist, and one line for the redirect. Similar approach when using some 
authentication. And for the case that each resource is supposed to use 
the same code, instrument each resource with an include. I'd use two 
independent script files for that, but I guess one could smush that into 
one file as well. And with include I mean using the PHP code word 
"include()", not copying the code into each resource. And even that 
could be automated. I have written self-replicating scripts that worked 
out OK unless I wanted to make changes.

I apologize upfront if my comments yet again generated an intellectual 
distaste. In that case, I give up and you are on your own.

Have a nice day,

David