Elliotte Harold wrote:
David Krings wrote:
But isn't that the old GET that has so many limitations that many web
app design guides basically tell you not to use it?
I have no idea what you're talking about. GET is GET. There's no old GET
and new GET that I've ever heard of.
Bad wording on my part. The talk went from states and sessions and
whathavenot to the Google URL example, which is nothing more than
passing form info via GET. It came across as this is a great new way of
solving the discussed issue, which indeed it isn't as it is a plain GET
mechanism that is around for ages.
It's certainly true that there are a lot of bad web app design guides
out there. Most of them try to reinvent client server on the web.
Uhm, isn't browser and server the purest form of client server? The
server doesn't to crap without the client constantly asking for it.
There are ways to improve that with AJAX or server side scripting like
PHP or a combination of both (which is needed when using databases as
the client cannot connect to the db server directly).
I wouldn't necessarily call the design guides all bad, but they are for
sure different.
They're like a manual for plastic molding machines that pretends the
molder is really just a funny kind of table saw and drill press. Follow
their directions and you'll develop problematic, unscalable
applications; and certainly lots of people do.
Which begs the question if every app developed needs to be scalable. If
there are at any given point in time no more than a few dozen clients
connecting scalability isn't an issue. So it depends. For the low
client, one site app I find sessions extremely useful.
And it depends on what you transfer in clear text as URL parameters. A
Google search is probably OK, but what if your application is about
sensitive data? You then need to craft identifiers that are dropped
after first use and never used again or some other untraceable
obfuscating mechanism.
No. You use HTTPS.
Understood....bit with all that security discussion, it is funny that
nobody focuses any effort on securing keyboards, mice, and monitors.
Many tests have shown that you don't need a password cracker, but just
some cheap equipment from Radioshack to record signals coming from input
devices. That just as a side note.
There was also the point made of scalability. As in this example, the
search results are not stored anywhere, but get recreated each time a
request is sent. That pushes the scalability issue from the web server
to the database server, where it may or may not be handled more
efficiently.
In point of fact, Google uses probably millions (maybe hundreds of
thousands but I expect millions) of servers. They need this massive
horizontal scalability. To make that work you really need to not care
which server processes any given request. Three subsequent requests can
and usually do go to three different physical servers. The more session
state you try to maintain the harder that is to handle.
By contrast, if you design apps so they don't need session state, then
you can scale horizontally very easily and you need a lot fewer actual
servers.
Understood as well...which is why Google and the likes drop sometimes
massive cookies on the client side. That addresses the scalability
issue, but is from a security standpoint somewhat questionable, which
again in case of a Google search is likely a non-issue. This is why I
routinely dump all cookies except for a few that I know I want to keep
for convenience.
David
_______________________________________________
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
