Ahh, I see what the issue is in general: there are currently no places in our app where we've got anything other than a two state flow: GET -> POST jumping to another flow is a completely different GET/POST pair, thus a new cookie and a new continuation. Two ways around this:
1) concatenate the continuation id's in the cookie, something like |c1|c2|c3|...|cn| then parse them as needed (treat it like a LIFO stack);
Hm... I cannot see how this would help. Continuations have there "stack" on the server side.
2) use different cookie paths for each flow that needs a separate state.
Keep in mind that the flow is not linear but can be tree based!! And there is no direct relation of path and continuation - even per client. You will understand as soon as you continue your flow in a new browser window.
This is pretty much transparent if set up properly and I think for us it would be simply a matter of using the page name as an additional path specifier: server/page/page and then ignoring the redundant information in the sitemap.
Can you elaborate a bit? I don't understand how this could help.
<snip/>
what do you do about the fact that you can't cache pages that have continuation id's embedded in them?
Well, as you say: it's a fact ;) ...nothing much you can do about it
cheers -- Torsten
