NYCPHP Meetup

[David Krings]

Elliotte Harold wrote:
> Which is exactly why we don't use sessions for such applications. 
> Instead the page of "next" search results is a URL like
> 
> http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N
> 
> That's an actual Google "Next" URL. It still works even though I've 
> pasted it into an e-mail and sent it to you, thus breaking any notion of 
> session.

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?
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.

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.

I do understand the limitation of sessions as well, which I wasn't 
really aware of before.

To sum it up: It sucks! One round of applause for the fat client who 
throws the strict client/server design principles out the window.


David