Re: the meaning of stateless

Mike Schinkel wrote:
> 
> And why are sessions bad?  Is it merely because of the identity
> problem mentioned above, or is it the fact that sessions disappear
> after a timeout and they would be okay if we created them explicitly
> and killed them explicitly?  Or is it something else?
> 

Server-maintained sessions are bad because they don't scale, since the
requirement for anarchic participation by intermediaries is they can't
be expected to maintain open connections to every origin server they
encounter, for the purpose of tracking session state.  I'd say easily
90% of the data transferred "in session" is invariant between users and
visits, so a better solution would be to cache that redundant data.

But, "sessions are bad" is too general; there's nothing wrong with
maintaining session state on the client.  Or persisting state between
sessions, on the client.  This doesn't require the client to always use
the same origin server, or the server pool to pass around tokens which
track session state, or preclude intermediary participation; so there is
no scaling penalty.

I think the "sessions are bad" paper tiger has led to many a squirrely
API making all sorts of round-trips in the name of "RESTfully" avoiding
client-side session state.

-Eric