Persistent sessions

[peter]

I find that I have the same requirement and would like not to 
re-invent wheels so would much appreciate hearing any insights you 
gained rg.

For local hosting, I used a persistent global session-ID counter as a 
patch (ensuring session-IDs can't overlap, but that's not acceptable 
for cloud hosting.
All I need really is persistence of the client's cookie validity, as 
all state data I keep outside HT.

So now I was thinking to modify start-session to be a fork for the 
make new session case. If the incoming request has no cookie, assume 
a fresh start so continue as of original start-session, otherwise 
take this as being an old session, now not found in the session DB. 
Hence make a replace session.

The session-ID seems irrelevant if I can search of sessions using the 
session string only. Hence make get-stored-session use string= on the 
cookie-string.

Ignoring overlapping session-IDs (they begin from 1 each HT boot), 
I'd need to eliminate reference to session-ID externally and embedded 
into the cookie string.

But now I get into session-verify etc and expect to run into awkwardnesses.
I don't fully understand the use of session-ID, why doesn't HT just 
use the vanilla cookie-string (without session-ID prefix) ... 
(despite it obviously being there for some purpose beyond optimized 
session-DB search). I can't yet get my head around how we can have 
multiple concurrent sessions to the same client, if that is the 
original intent. If not then why use the session-id, and why both 
externally as session-DB index, and internally in the cookie-string 
as in stringify-session.

peter

At 6:59 PM -0800 14/1/17, Ron Garret wrote:
>I need to be able to save and restore HT sessions so that they will 
>survive a server restart.  Before I dive into this I thought I would 
>ask if anyone has done this already so I don't reinvent the wheel.
>
>Thanks,
>rg