You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Conal Tuohy <co...@paradise.net.nz> on 2002/06/18 23:04:18 UTC
Continuation as cookie? (was RE: [RT] Flowmaps)
I haven't yet used the flowmap stuff myself, so I have a possibly naive
question: what would be the flowmap (flowscript?) syntax to return a
continuation to the client as an http cookie? Is this relatively easy
compared to url-rewriting?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Continuation as cookie? (was RE: [RT] Flowmaps)
Posted by Ovidiu Predescu <ov...@apache.org>.
On 6/19/02 5:29 PM, "Vadim Gritsenko" <va...@verizon.net> wrote:
>> From: Ovidiu Predescu [mailto:ovidiu@cup.hp.com]
>>
>> 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).
Right.
> [...]
>
>> 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).
You can always reuse a continuation id. If you know the continuation id (you
can retrieve it from the first continuation you create), you can store
subsequent continuations under the same id. I'm not sure you have support
for this exposed in JavaScript right now, but it should be fairly easy to
add.
Regards,
--
Ovidiu Predescu <ov...@apache.org>
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
RE: Continuation as cookie? (was RE: [RT] Flowmaps)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Ovidiu Predescu [mailto:ovidiu@cup.hp.com]
>
> On 6/19/02 12:25 AM, "Sylvain Wallez"
<sy...@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 <ov...@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
Re: Continuation as cookie? (was RE: [RT] Flowmaps)
Posted by Ovidiu Predescu <ov...@cup.hp.com>.
On 6/19/02 12:25 AM, "Sylvain Wallez" <sy...@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. 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.
>> 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 ? 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. 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.
Greetings,
--
Ovidiu Predescu <ov...@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
Re: Continuation as cookie? (was RE: [RT] Flowmaps)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>
>>Conal Tuohy wrote:
>>
>>
>>
>>>I haven't yet used the flowmap stuff myself, so I have a possibly naive question: what would be the flowmap (flowscript?) syntax to return a continuation to the client as an http cookie? Is this relatively easy compared to url-rewriting?
>>>
>>>
>>>
>>You can't do that, as the cookie has only one value, which makes it
>>perfect for session management but unusable for continuations : each new
>>
>>
>
>I'd like to oppose, can I? :)
>
>
Of course you can !
>>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.
>
>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 ? IIRC, Ovidiu already talked about this, but I don't
remember exactly what he said.
Ovidiu, what's your opinion on the above ?
>>by trying different possibilities in different windows, thus leading to a tree of continuations.
>>
>>
>
>Just suppose for a moment that your app requires one and only continuation.
>
>
Don't you call it a "session", then ?
>Mmm... I already see where it can be used... :)
>
Teasing, teasing ;) Please tell us more !
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Continuation as cookie? (was RE: [RT] Flowmaps)
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Conal Tuohy wrote:
>
> >I haven't yet used the flowmap stuff myself, so I have a possibly
naive
> >question: what would be the flowmap (flowscript?) syntax to return a
> >continuation to the client as an http cookie? Is this relatively easy
> >compared to url-rewriting?
> >
> >
>
> You can't do that, as the cookie has only one value, which makes it
> perfect for session management but unusable for continuations : each
new
I'd like to oppose, can I? :)
> 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.
If you add continuation persistence on server side... In *this*
scenario, cookies *do* make sense. Don't you agree?
> by trying different possibilities in different windows, thus leading
to
> a tree of continuations.
Just suppose for a moment that your app requires one and only
continuation.
Mmm... I already see where it can be used... :)
Vadim
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies Apache Cocoon
> http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Continuation as cookie? (was RE: [RT] Flowmaps)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Conal Tuohy wrote:
>I haven't yet used the flowmap stuff myself, so I have a possibly naive
>question: what would be the flowmap (flowscript?) syntax to return a
>continuation to the client as an http cookie? Is this relatively easy
>compared to url-rewriting?
>
>
You can't do that, as the cookie has only one value, which makes it
perfect for session management but unusable for continuations : each new
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
by trying different possibilities in different windows, thus leading to
a tree of continuations.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org