One of the reasons I like blogging is that writing about a subject forces me to consider it in more depth than I would if I were just mulling over it in my head.
For example, I sat down tonight to write a sanity-check about continuation-based web programming, and in the process of gathering my thoughts on why I'm wary of the idea, I've managed to develop significantly more respect for it than I had before I started writing. As I examined each of my issues with the concept in enough detail to write about them, I discovered they weren't really problems at all.
Except one, at least with the two frameworks I looked at.
In the oft-cited Smalltalk continuation framework Seaside and it's Ruby port Borges, all links are anonymous callbacks, and thus are meaningless, transient strings bunged on the end of the application's base URL. The developer of Seaside has this to say about it:
People often complain about having "meaningless" numbers in the URLs, but they enable a level of abstraction over HTTP that wouldn't otherwise be possible.
To me, that's a deal-breaker. The URL is a Uniform Resource Locator. Making URLs no longer point to resources takes an enormous amount of the web's power away in order to make the programmer's life easier.
As a random example, take web stores. I can copy an Amazon URL from my location bar, paste it to a friend in e-mail or an IM, and that friend will see exactly the same product that I'm looking at1. Whenever I go to a site, find something I want someone else to look at, paste them the URL and discover they've encountered a "This is not your session" message, I make a strong mental note to avoid that site in the future.
Getting rid of bookmarking and deep-linking essentially lobotomizes the web, and to me makes such frameworks useless for most public-facing web applications2.
Even for internal systems: ever implement a login system for a web application? There's a reason that the post-login redirect has to take the user to the deep-linked page they were trying to reach originally, rather than the application's front page: users demand it.
1 If you can do this with Seaside, it would essentially be session hijacking. Even more nastily, the continuation-based approach would mean someone who intercepted a URL (or dredged it out of a recent browser history file) would be able to seamlessly resume some other user's session at an arbitrary point.
2 The most likely exceptions being completely private applications with a shallow interface such as web-mail or banking.
I agree that writing a web application that's solely based on continuations and auto-generated urls is a bad idea. In RIFE (http://rife.dev.java.net), continuations are available at an element level and elements can be mapped to urls. The continuation is determined by a contid. If the id is abscent, the logic will start executing form the start of the element that's first processed by the url, instead of resuming somewhere else in the code. This makes continuations very convenient for isolatable blocks of logic (typically a wizard, a game, ...) and still allow direct access to publically accessible parts. In fact this makes the web more usable since there really isn't a reason to be able to jump to the 2 page of a wizard directly, while (as you say so clearly) linking to, bookmarking or copy/pasting the entrance makes a whole lotta sense.
Another thing, RIFE only retains the local variable scope of the executing code, not the data flow across the http barrier. This means that even though your variables are restoring themselves, you still have access to query string or form parameters. Which integrates much nicer with the meaningful URL model.
Seaside is used to build web applications. We are past the old web's usage of static content. Just as you can't send an address to a friend of IM which will bring him to a particular place in Microsoft Word or in Warcraft III, you can't do that with Seaside applications.
My response is here: http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3256899497 . Short version: why choose between meaningful URLs and continuation IDs? Use both at once.
Just penning some thoughs.
There are applications with a web interface, and there are web sites that work like applications.
I'm looking at tapestry and some other component driven web application frameworks. I'm also in the process of developing a simple prototype to test some of the concepts in my mind.
With most applications, an email client for example, you have to start up, view the main page, then navigate to which "view" or "page" you wish to operate in. Is there a concept of a "bookmark" in this example?
By deeply linking the Amazon URL, that's a function of it being a website more than it being an application.
From what I can tell, continuation based programming again stores this state on the server, such that calling the same URL does not give you the same resource. The function of the URL is not as a "Resource Locator". It is more of a command in the form of a url address.
Is that a deal breaker still ?