Good point. So far everything I've made uses Swing clients, so I haven't
really thought about the limitations of using cookies. I would have to
agree on the use of session. They shouldn't be included in Restlets. I
was always weary of using sessions in Servlets. Seemed like a lot of
people didn't mind just dropping anything in there, and most probably
just let whatever framework they use handle it. If anything state could
be added as an extension. Maybe just to the limit that Restlet supplies
a simple set of classes to handle setting and getting a unique cookie
from the client, and relaying it to a handler. That said, is an
extension even needed? It would be pretty simple now as is. Maybe just
some documents telling how, for developers that must have it. Overall I
pretty much completely agree with what you've said so far.
Rob Heittman wrote:
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?
--
Justin Stanczak
Stanczak Group
812-735-3600
"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
