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.
The goal here is to avoid having to manually create and maintain
separate files for each URL. One file: many URLs. That's the goal.
Imagine, for example, a site with a separate URL structure for each
user, or a separate URL for each date in history.
The point about this being an Apache problem rather than a PHP problem
is understood, except that Java/Tomcat/mod_jk does seem able to
accomplish what I'm looking for, so the real lack may not be in Apache
but in now PHP connects to Apache.
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.
I'm curious if they're any web servers out there that do not start with
the assumption that each URL maps to a file somewhere. What if a web
server were designed to allow all URLs to be delegated to specific
handlers? A file system handler need be only special case, no different
from a database handler or a PHP handler.
RESTful API *design* is fairly easy to do. RESTful API *implementation*
is fairly hard because no servers I've seen provide sufficient
flexibility. Coming up on the Web's 20th anniversary, we still haven't
learned how to take HTTP on its own terms rather than by pretending its
something else we're more familiar with. Revolutions take time. :-)
--
Elliotte Rusty Harold [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
