Rob Heittman wrote:
Great article, Serge!
I would offer this viewpoint on the Session concept. The transparent
instant availability of an general-purpose Session, as in JSP/Servlet,
is ridiculously convenient for about a billion reasons, and therefore a
powerful seduction to not really engineer the concept of state and how
it applies to your application. This can cause excessive session
proliferation and sometimes user frustration, when some operation that
should not be expiring in nature suddenly fails because your session
expired (for example, my Zimbra mail client, which I otherwise love,
does this to me occasionally). And because the typical JSP/Servlet
session is a cookie-per-browser Session, and not tied to an individual
browser window, Session reliance can cause ugliness when users have
multiple windows open to your app. Not everybody remembers that *all*
the time. (I'm so guilty as charged).
indeed, rather then a 'session' per launched client (all windows) most
applications would want a session per started use case (separate window)
this allows e.g for some service-operator to let a multi-page
data-entry-use-case (s)he is doing to process a received mail-order
_wait_ in parallel while answering the phone and processing a second
real-time request coming in with the same application (different
instance of same use case in a separate browser-window)
(yeah, having sweet memories from good old cgi days when we had shell
scripts using the $$ process-id to keep some server-side state on file,
and pass URL's back and forth with some coded version of that)
I'm not implying that session abuse is true in your case :-) Nor that
it is reasonable or even possible to implement a meaningful application
totally free of the session concept. But we have found at our shop that
a lot can be gained by having to think about state, instead of always
having "stuff it in the Session" as a omnipresent crutch. I kind of
like that Restlet raises this barrier, though I agree with your
I think we should follow the pragmatic lead of a book like restful
webservices here: what I think I read there:
1. it might take some exercise, but most 'things' can be seen as
resources (rmember the transactions example in there)
2. there is a difference between resource state (should be on the
server) and application state (should be kept on the client)
IMHO it is a thin line to walk, and while the more important part of
that last point is that everything on the server should be a _resource_
(addressable, linkable, ...), there are still some options open to those
resource-beasts:
a. IMHO resources don't need to be persisted on disk (in fact even if
they are, still a cache could be serving them from memory nevertheless)
b. resources have an accepted _limited_ time to live (they don't
exist until they're created an after some time some DELETE or even a
side-effected POST can make them dissapear again)
(which makes me think about the files^H^H^H^H^Hresources in my linux's
/tmp here)
Given the above, I think the 'resourced' way of keeping some
(admittedly) application flavoured state up at the server would be to
create temporary 'resources' that allow to store some use-case related
state.
That resource-state should most likely
- be bound to individual started 'use-cases'
- be holding some relevant taken decisions up to now
(euh, yes, that should even include things like continuations
in my mind)
Given the temporary nature of these things I can imagine a certain
reluctance to persist these on disk (or if that sounds less bad: leave
it to some cache manager to decide to do so)
hypothesis that somebody will inevitably offer it as an, er, option.
Well, I'm +1 for keeping out the cookie based sessions, but I'm also
quite sure thin client application development will keep on relying on
some sort of server-side temporary (application-like) state.
So rather then waiting for that to be added in the "bad" way, I think
restlet should bravely tackle the issue and provide a proper way for
keeping 'temporary' resources in a flexible and efficient way. (Which
includes the less joyful job of cleaning up those when their 'memory
lease' runs up...)
Well, I know it's a fair bit of dry theory and/or voluntary speak above
here, but my early playings with restlet give me the idea this could
really be the basis for it, I'm just not well versed enough in the
internals to propose an idea of how it could be done, anyone else?
regards,
-marc=
