Re: Temporally extended sessions

Tim Bray wrote:
> ...
> 
> 
> Indeed, I regularly access my bank account through a web browser, with 
> all sorts of session semantics - get account balances, pay bills, 
> transfer funds, etc...  At one level I'm horrified by the kludginess of 
> the techniques the server uses to fake session context, but hey, it 
> beats standing in line in front of a teller. -Tim

And in a context where the client is smarter than a web browser, there 
is no need for kludginess at all. The session is a resource, just as it 
is surely an object in the client and server code. It has a URI, just as 
it surely has an address in the client and server code. It has a 
representation, just as, etc. etc.

This strikes me as not just elegant but extremely functional. Consider 
on the one hand telnet and FTP. Sessions in these protocols do not have 
context-independent names and state retrieval protocols so it is 
impossible to start a session on one client machine and migrate it to 
another. Conversely, you can use the "screen" program to make sessions 
first-class addressable objects with downloadable state. That makes it 
possible to move the session between client machines. The only reason I 
could imagine to prefer the former design is to avoid doing the little 
bit of extra work required to make the session addressable. 
(statelessness is of course another issue, screen is stateful!)

  Paul Prescod

Received on Thursday, 30 January 2003 17:14:35 UTC