Comment

Above in this comment thread: The Elevator Pitch for Web Based Continuations » Wrong Idea » dead wrong » Continuations:Web :: Sequential/Modal:GUIs » More on continuations

UI state <> Business Object state

Posted by Anonymous User at 2003-11-24 09:28 AM

"""Of course the continuations approach is for stateful applications. Which serious business orientated applications do you want to write without state?"""

You're not distinguishing between stateful UI and stateful objects. Business applications have to have stateful objects. They do not have to have server-side UI state.

"""As long as you can rely on stateless applications fine - but what happens if your requirements grow? How can you implement the fact "a user is logged in" without a state on the server in a safe way?"""

Ummm, how about...

A cookie containing a server-signed ticket
Basic auth over HTTPS
Client-side HTTPS certificates

Just to name a few. How many ways do you need?

By its nature, HTTP doesn't put state on the server side. This is good, because it allows scalability through caching and clustering - and the caching and clustering can be much simpler than they would be if there was UI state to store along with business object state.

Web applications are easiest to build when you design the UI such that all state is divided into either persistent business objects, or client-side state, and client-side state consists solely of URLs and perhaps a cookie or two to identify a relevant business object.

If you don't follow this division, you end up duplicating persistence mechanisms, and important business data may not be properly backed up because it's living in the web tier.

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.
The web tier is more scalable when state is stored either in the client or the DB tier
The business is better off with its business objects identified as part of the business model, and put in the enterprise's data tier.
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.

Who are you?

Posted by Anonymous User at 2003-11-24 12:22 PM

This makes so much sense (http based programming, not continuation based).

I have build high-performance sites, where it was super easy to customize or add new functionality. With continuation (event driven and server state driven), the whole web site acts like a single desktop application. The beauty of http driven model was that the interface between components was very limited (form or url variables). People had to think hard and had to write clear requirements of the component. e.g. A product display component would take product number or product as part of parameters and then display the product. Now with event based programmnig the event first hits the page that renders the button/link for that event, who must know how to call the component. With http based method, you only worry about the url/form-action and the parameters. Hetrogeneous systems can integrate very easily with this simple method, instead of depending on next action handler being callable on the server side.

With event/state driven programming, basic browser functionality stops working. Back buttons doesn't work, bookmarking doesn't work. You end up coding back button on all the pages manually and disabling the broser back button. It really gets ugly.

If you learnt UI programming first, before web programming. The frame of mind is already set on event/state based programming. It's a bad thing in my opinion. HTTP parameter based programming is much more scalable (linear scaling) and interoperable.

My 2 cents. Prashant Rane http://www.jroller.com/page/prane

Continuations-based controllers do work

Posted by Anonymous User at 2003-12-02 12:26 AM

> 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.