Hi Justin,
Purely practical cookie issues:
1) Browsers that follow the original Netscape cookie definition limit a single
cookie to 4096 bytes, with a maximum of 20 cookies per site. Due to encoding
issues and overhead your actual storage limit will vary by a few bytes. IE
recently increased 20 to a maximum of 50.
2) Browsers often have cookies limited in other ways (not accepted at all, not
accepted beyond the browser session or across hosts even though you say so, not
accepted unless they match certain known names, etc.)
3) Cookies are per browser. They don't identify multiple browser entries into
your application.
4) The browser sends EVERY COOKIE back to the matching paths on the server in
the header of EVERY REQUEST. If you poke a whopping 200K of not-path-restricted
cookies at a client, now that client will send 200K of data upstream every time
it ... i donno ... fetches an image or a CSS stylesheet or something from your
server. So the Netscape-designed 60K limitation was sensible (and Microsoft
shows the usual consideration by changing the limit to 200K for the world's
most common browser). If the trend continues, any predictions on how soon
hosting providers drop their "upload bandwidth is free" policies?
If the entire amount of state you want to persist is guaranteed to fit in less
than 4K (or you can rely on some kind of splitting approach to set multiple
cookies for more storage), and you can be sure your clients will accept your
cookies and respect the limits you set, and you really want per-browser
sessionality, this is probably all the mechanism you need.
Theoretical cookie issues (with idiomatic Session use, not the
XML-cookie-storage you described):
The limits on cookies were one impetus driving server platform vendors to
establish a server-side bag of Sessionality, sending a small cookie to create
affinity with it, and eventually for the application server community to
canonize this as the default idiom. Maybe this happened because the first round
of commercial Web application servers had various session management features
as a big selling point, and everyone with time to write documentation and
examples wanted to make sure everybody used the heck out of 'em.
But when you elect to keep state on the server, the server needs storage for it
(which may not scale in the large), and the server must be responsible for
managing it (which means it has to persist across restarts, must be available
from all cluster nodes, etc).
And when you elect to use a cookie as the key to a server-side bag of state,
you must accept that the scope of that state is per browser instance and
nothing else.
These are valid choices, but I think they are choices that developers should
actually make , and there are lots of alternatives. Take away the Servlet
Session, and how many of the extant servlet-based applications in the world
would be mortally wounded and need significant porting? 80%? 90%? I'm not a
rabid RESTian by any means, but I can't make myself believe that a server-side
hash full of state with a cookie-based key was the right choice for all of
them.
Restlet *does* take away the Servlet Session, and thereby makes a developer
think what they're going to do without it.
This thinking process, I feel, takes two forks:
1) Calling a resource a resource
Typically the stuff that one might put in the Servlet Session (e.g. the
contents of a shopping cart or the result of a database query) is really a
server-side resource. I advocate giving some thought to where it should live
(on disk? in memory? as a symbol that's reified only upon access?), instead of
being seduced by a default which does not fit all cases. This is where I think
Marc was going -- for Restlet to provide some handy options for this. And after
reading some other people's code today, I fear that maybe the seductive default
in Restlet is to stow everything in a file, and that's not really good either.
So maybe an expanded library of Client connectors and some semantics for
defining and expiring transient resources is the brave way forward that Marc
called for. If you're still reading, Marc, what would you think of something
like a new Client(Protocol.TEMP) that let you name and operate on resources
that are meant to be transient?
2) Whatever does not actually need to be a server side resource, try hard to
give to the client. It won't hurt and it's what users expect.
Users want their Back and Forward buttons to work. They want to be able to
visit a 4-day old page in their browser history and pick up from where they
left off. They want to slap their laptop shut at LAX in the middle of an
application session, land 13 hours later in Sydney, snap it open and continue
without interruption. They want to open three simultaneous Firefox windows to
your application and do different things in each one. They expect these things
because that's how Web sites (not necessarily Web applications) work, and
therefore that's how they expect everything on the Web to work.
Adherence to the client-side state rule makes a lot of this ... just work. The
representation you send -- the page itself -- the form or whatever -- is
supposed to contain "all the information necessary to understand the
request[s]" that might originate from that representation. That doesn't
actually preclude the keeping of server side application information (as Yuri
just affirmed). If you are on Step 3 of a five-step e-commerce checkout
process, your Step 3 page could actually contain all the carried over data from
Step 1 and Step 2 (e.g. hidden fields), or it could contain some kind of
identifier pointing to a server-side resource that held previously entered data
(/app/v1/orderforms/{id}), or your browser could send a cookie that contained
that identifier (if you want multiple browser windows to always point to the
same resource). In any of these ways, the server has sufficient information to
understand the request and act on it.
/rant
:-)
- R
----- Original Message -----
From: "Stanczak Group" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, September 5, 2007 7:07:25 PM (GMT-0500) America/New_York
Subject: Re: sessions debate (was Re: some benchmarking)
Really I had planned on creating an interface that uses something like
XStream with Cookies.
Stanczak Group wrote:
> So why do cookies not fill this session gap? Is that to much client
> side dependence?
