[nycphp-talk] AJAX and State
ramons at gmx.net
Fri Sep 7 12:52:18 EDT 2007
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
> 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
> 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
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
More information about the talk