I played with my own continuation-based framework just around the time

that SISCweb was released (which was much better written!), so I

didn't continue with it beyond a proof-of-concept. I also came across

the 'deep-linking' problem you outline in your write-up.

A solution (not a great one I realise) I implemented was as follows.

I reasoned that in most apps, there aren't that many places which

you'd want to actually stop and bookmark it, to return later. You're

never going to bookmark yourself half-way through a credit-card

workflow. Indeed, taking Amazon as an example, pages you'd want

'bookmarkable' would be individual books, your wishlist, and a couple

of others.

You'd only really have a few 'entry-points' or 'significant functions'

in the app, for instance

- view book

- view wishlist

- view frontpage

- view specific comment on book

from which, of course, you'd have k-urls pointing all over the shop.

But as soon as you started from one of those entry-points, the

function would register 'bookmarkable url parameters' such as book-id

and always redirect requests containing k-url paramters to ones which

contained, for instance, a book-id parameter. The page generated by

the following the k-url (ie pages within a current user session) would be stored

temporarily in a hash table, the redirect would bounce the user to a

page with a good URL and a sentinel value. The stored page would be

retrieved from the table and shown, and be removed so that the

redirect would only work the once.

If the page did not exist (ie had been removed from the hash table,

having been served as a redirection end-point) then the

bookmarkabe-url-paramters would be decoded, and the user would start

afresh from the 'entry-point' function appropriately, possibly having

to login again.

At the -- significant -- cost of a redirection per page, I was able to

have meaningful, bookmarkable, safe URLS, which didn't contain k-urls

which could be security risks. It also meant that you couldn't

bookmark from within a complicated bit of workflow transaction, but I feel that's a thing that

users just don't naturally want to do: it feels naturally weird.

Not a great solution, but quick and dirty. The code was slightly

hairy, but I reckoned with better macrology I could have made it look

fairly clean to a developer who didn't delve too deeply (-: