NYCPHP Meetup

[Elliotte Harold]

Kenneth Downs wrote:
> One thing that seems to have gone unsaid in the praise for Ajax is its 
> ability to radically transform how we maintain state.
> 
> The web server session is our basic mechanism for storing information 
> between requests.  But it gets clumsier and clumsier to try to maintain 
> complex state across many page requests when you use a session.  
> Ingenious minds have put their will to the problem and come up with 
> workable systems, but all of them are complicated because of the nature 
> of the problem.

There are no sessions, or at least there shouldn't be in well-designed 
Web applications. There's resource state (on the server) and there's 
application state (on the client). It sounds like you're in the process 
of reinventing REST. In particular you've noticed that keeping 
application state on the server is a royal pain that severely limits 
scalability.

However this has been known for a long time. Indeed one of the primary 
design principles of HTTP is that application state is not stored on the 
server but is transmitted with each request. This was true long before 
AJAX or even JavaScript. Usually the appropriate place to put such 
application state is in the URL, though sometimes what we initially 
think of as application state can be recast as resource state.


> That problem, stated here, is simply the problem of tracking what I'll 
> call the "context" of a user's session.  Some elements of a session are 
> fixed: the user id, the password, a few other things, but almost 
> everything that we need to track is always changing.  A basic example: a 
> list of search results.  Where do you store it?  When the user hits, 
> "NEXT PAGE", how do you know what to do?  If you are using a session, 
> what happens if he opens a new window and has two search results sets up 
> for two different tables?

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.


> Ajax solves this problem neatly by letting you move all state [1] into 
> the browser.  This makes sense from an architectural viewpoint because 
> we are putting this context information close to where it is needed, the 
> UI.
> I've been converting the basic Andromeda UI code over to a completely 
> AJAX system [1], and have found my code radically simplified and far 
> smoother, due almost entirely to the moving of all state information to 
> the browser.  Hurray for Ajax!

Hurray for REST!  AJAX or no AJAX, this is the right way to design a web 
application. There's a really excellent book out now from O'Reilly 
called "RESTful Web Services" that covers this in detail.

> [1] Here I'll use "state" to mean the changing context of user requests, 
> and assume we are still using the session for User_id and password.

You still have a problem then, though perhaps your systems haven't yet 
grown big enough to have noticed it. But it will kill you when you need 
to scale beyond one server. The authentication info needs to be 
transmitted with each request also.



-- 
Elliotte Rusty Harold  elharo at metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/