Hm... I cannot see how this would help. Continuations have there "stack" on the server side.
In general you're right it's not useful, you'd only be able to support this with a back button on the page that told the server to pop the stack. You wouldn't have browser back button support.
I still don't see the gain...
You basically have a tree of continuations on the server side. You don't have to "pop the stack" to show a particular leave.
<snip/>
The issue is, in general, you want to associate a continuation with a particular user and a particular page. As you point out, using a single cookie doesn't work for the general case since you loose the per page association.
*nod*
However, a somewhat more general solution is to exploit cookie paths to allow one cookie per page.
ok
> To do this you have to have
a unique path to each page.
ok
> The cookie rules are that you can look down
the path but you can't place a cookie at a place higher up the path than the page. IOW, sever/x/x.html can have a cookie at path "x" or at "/" but not at "x/y". So, you basically hack Cocoon to add a redundant piece of path information to each page request that you then factor back out in the site map.
So if IIUC you then can store a continuationid per page.
But that's not enough: you can have n continuationids per page! Maybe not much likely to happen very often - but not totally far out.
This works, I tested it yesterday, but I've since
Did you try when you duplicate you browser window?
thought of a better solution which I'll post later today once I get a chance to test it. (The general problem is that not all sites can allow the page paths to be hacked in the manner I describe...)
Eager to see what you bring up here :-)
Well, as you say: it's a fact ;) ...nothing much you can do about it
I think there is :-) look for a post with a title something like
"Continuations break caching - possible solution" later today...
Did I miss it? Or am I still waiting :-)
> The
solution still requires session management, but it's more general and easier to implement than what I've been playing with so far.
Are we talking about server side or client side caching?
Of course you *could* have each page cached. But 80% of the user actions would create a new page and place it into the cache because the key of the page has to include the continuationid. Otherwise external entities like flow variables would not correctly be reflected.
I really doubt a fully cachable pipeline is possible or does make sense in that context.
cheers -- Torsten
