Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Vadim Gritsenko" <vadim.gritsenko@verizon.net>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Continuation as cookie? (was RE: [RT] Flowmaps)
Date: Wed, 19 Jun 2002 20:29:32 -0400
Message-ID: <026601c217f1$8c994f90$0a00a8c0@vgritsenkopc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <B93669BD.631F%ovidiu@cup.hp.com>
Importance: Normal

> From: Ovidiu Predescu [mailto:ovidiu@cup.hp.com]
> 
> On 6/19/02 12:25 AM, "Sylvain Wallez"
<sylvain.wallez@anyware-tech.com>
> wrote:
> 
> > Vadim Gritsenko wrote:
> >
> >>> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> >>>
> >>> page leads to a new continuation. This is how the infamous "back
button"
> >>> problem is elegantly solved, and also how you can use what-if
browsing
> >>>
> >>
> >> I could imagine application which has one and only continuation per
> >> client. In this scenario, when client hits "Back" button,
application
> >> shows to the user *same*, *current* page but not *previous* page.
> 
> But is not the application that shows the page, it's the browser if it
> maintains them in a cache. 

This is not an issue, and can be controlled by HTTP headers.

For example, in IE, I never can get old front page of slashdot.org:
every time I click "back" it goes back to server instead of showing
stale page. Same for online banks (at least my CU).


> The continuation id helps identifying the state
> of the program on the server side, but this gets transmitted only when
you
> make a new request from an old page.

I see.


> >> If you add continuation persistence on server side... In *this*
> >> scenario, cookies *do* make sense. Don't you agree?
> >
> > Yes, cookies do make sense for this. But in that case, do you really
> > need continuations ? 

I thought about it a bit. Yes, continuations even in this scaled-down
scenario *do* make sense, because if you have complex application logic
and do not want to code FSM, continuations are the way to go.


> > IIRC, Ovidiu already talked about this, but I don't
> > remember exactly what he said.
> >
> > Ovidiu, what's your opinion on the above ?
> 
> The problem is that a cookie does not change when you hit the back
button in
> your browser. An application could have many continuations, and each
> continuation will have its own id.

We are discussing here single-continuation-applications only.


> Thus, each URL which generated for a
> continuation will be different than all others. Your browser will
maintain
> the history of URLs, as opposed to the value of your cookies. A cookie
has
> only one value, no matter what you do with your browser history.
That's why
> you cannot use cookies to represent continuations.

If ID generation is uncontrollable (can not have one and only number
instead of new one every time you continue), then yes, it is (almost)
impossible...

...Because another way is to save continuation ID into session and on
every request you can match continuation ID from session and retrieve
*current* continuation (and page) instead of previous page :)

But, cookies here do not play any role (except session handling).

Vadim


> Greetings,
> --
> Ovidiu Predescu <ovidiu@cup.hp.com>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU,
Emacs...)


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org