> So, to sum up, I believe that putting state in the web tier > is a bad idea because:

> * Users are better off with client-side state, where they can > control, bookmark, forward, re-purpose as web services, etc

As long as you use simple HTTP GET with name/value-pairs you're right - the user can bookmark every state. I wonder if it is always intended that a user should bookmark every state. All other "advantages" are possible with continuations too.

> * The web tier is more scalable when state is stored > either in the client or the DB tier

hmmm, why?

> * The business is better off with its business objects > identified as part of the business model, and put in the > enterprise's data tier.

What has this to do with contination based controllers?

> * It's duplication of effort to create two persistence mechanisms, > one for business objects and one for UI state, especially when it's > always possible to model a piece of state as either client-side > state or as a business object.

There is no duplication of efforts. There must be one "instance" that controlls the application. In your case you have resources and the controller is coded into the links of every!!! single page which is IMHO a very ugly approach. Maintainence (and reusibility) becomes difficult and expensive, sometimes impossible. A continuations based controller is a controller which is a sequential program, easy to understand and to maintain. Additionally there a some security and bandwidth concerns if you use pure REST.