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 [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
