Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3EF0070D.4000409@outerthought.org>
Date: Wed, 18 Jun 2003 08:30:37 +0200
From: Marc Portier <mpo@outerthought.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [vote results] FOM
References: <BB156805.20339%pier@betaversion.org>
In-Reply-To: <BB156805.20339%pier@betaversion.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Pier Fumagalli wrote:
> On 17/6/03 22:51, "Stefano Mazzocchi" <stefano@apache.org> wrote:
> 
> 
>>> - Should the flow _always_ be associated with a Session?
>>
>>I haven't written a flowscript that didn't require, in some way or

sure

>>another, the availability of some statefulness on data and it seems to
>>me as overkill to use full execution state preserving (and the
>>URI-encoding of the continuation every time!) just for the data
>>(besides, even today, if you want to keep global flow variables around,
>>you have to enable sessions anyway)
>>

but this is only a limitation of the current implementation IMHO
generaly speaking the web paradigm offers other mechanisms then 
sessions to maintain state!

>>In general, it is true that continuations and sessions are different
>>beasts, but in real life, continuations *extend* sessions since they
>>provide the ability to save *even more* state than sessions.
>>

again, I _think_ this is based on current angle of attack of 
continuations

>>But in those situations where procedular flow is weak and navigation
>>decisions are driven by user action and not by flow execution,
>>continuations are overkill and sessions are still the preferred way to go.
>>

half way agree:
where procedural flow is weak and navigation decisions are (also) 
driven by user action and not (only) by flow execution, 
continuations are overkill, but next to sessions we could still 
maintain state in temporary resources with their own URI's

>>is there a real need for continuations without sessions? i really can't
>>provide a meaningful example of this.
>>

I tried to explain this before and badly failed.
I think sessions are *very* limiting beasts, my guess would be to 
use them for what they are useful, being as Pier explains here 
some kind of client-user-agent-tied-singletons

>>so, I would say +1 to this.
>>
>>if you are against this, please speak up now.
> 
> 
> Pinching in at the last minute, as I'm completely overswamped by work at
> this time (writing a template engine, u know, can be hard)...
> 

Pier, thx for taking the time to put down so clearly what I 
haven't been able to communicate

> We've got some _serious_ problems with sessions lately at VNU. The problem
> we faced is that in 99.9% of the containers out there sessions, by
> containers, are identified uniquely with a cookie stored on the client side.
> 
> What does that mean? That no matter how many browser windows you have open,
> your client will uniquely be identified by the server as "one".
> 

precisely.
sessions limit the end user interaction possibilities: they can 
only engage in one interaction (use case) of a certain type.

> Our problem lies in the multitasking ability of one client, so to say, to be
> able to continue two instances of the same flow at once.
> 

yes.  but putting the 'problem' as a challenge we get: this 
multitasking ability is something an application should be able 
to use to its advantage: your web-based application should be 
able to expose the same kind of multitasking ability people are 
used from their typical desktop app, no?

> We have a "registration centre", where people can mail (snail mail) and
> phone in to subscribe for VNU's different magazine offering.
> 
> Let's take this example: one of our kids at the registration centre is
> entering the details for one subscriber, whose information he got through
> the post, she has a card in front of her, and goes through several web pages
> (a some sort of "flow") to enter (or rather copy) the user registration
> card.
> 
> At the same point in time, the same person gets a call on the phone, he/she
> needs to follow the SAME EXACT FLOW, but in a different "instance" (pausing
> the "card-based" registration, and doing the same thing but asking the
> details from the guy on the phone).
> 
> Now, if my "flow" is somehow stored in the session, which is stored in a
> cookie, the "card" registration details, and the "phone" registration
> details get messed up, as the server has no way to figure out that the same
> client (identified by a cookie) is doing two "instances" of the same thing
> at the same time.
> 

yep,
my idea would be to kind of 'enter an interaction or use case' on 
a general URI in such a way that an interaction instance of that 
type is created with an associated specific URI that from then 
depicts a certain temporary resource.  The resource itself is 
where the state is (quite ReSTy as well)

> We solved this by switching our servlet container to Jetty, which has a nice
> feature "forcing" itself to completely ignore cookies and by URL-rewriting
> every link and form action. By forcing this, we now have the opportunity to
> have uniquely identified "per-task" based sessions (based on URL-rewrites),
> rather than a global "per-client" session.
> 

absa...
the URL-rewriting thingy is equal to having the mentioned 
interaction-instance-specific-URI's

inside these specific URIs you can even point to subresources 
that enable the user-action-triggered navigation while staying 
inside the resource state (i.e the same interaction instance)

all without the need for (and the limitations of) sessions

> Given the current implementation of sessions on servlet containers, it's so
> easy to F-word-UP is the client opens a new window and tries to do something
> different (the client will either completely ZERO whatever task he/she is
> doing, or mix up the session data), unless you don't force
> URL-rewriting-with-cookie-ignoring (which AFAIK can be done only w/ Jetty).
> 

I have been trying to put down something like this inside cocoon 
so we could use it regardless of the container
(have some code but not quite finished, however I haven't felt 
myself able to express clearly enough on how it could be done to 
be able to grab interest for a larger discussion on this kind of 
stuff, which input I probably need to really get it finished :-))

> Think about a continuation like an instance of a "task" stored on the
> server, while unfortunately you have to realize that a session is the
> instance of a "client" (with all its tasks) on the server.
> 

YES!
Perfectly put.
However the use of the word 'continuation' could become very 
confusing for the ones currently active in flow...
There a 'continuation' really has the meaning of a 'frozen 
execution-stack' while the idea here is about more passively 
holding the state of a specific 'instance of a task' (or use case).

I think both approaches have their value (will be best suited to 
cover a range of specific problems), and I would hope that lots 
of pipelines and interfaces could be shared between them.
In fact this is where I would see that Flow != Continuations but 
rather the umbrella way of working where both could fit under.

> Kinda like multiplexing, multiple tasks on the client, multiple tasks on the
> server, only ONE and only ONE (in most cases) session between the client and
> the server...
> 

yep, there is even an extra feature this approach is throwing in 
by separating server-tasks from clients: you can lower the access 
control so other people can engage in 'your' interaction-instance 
(since it is just a URI you can have the access to it handled on 
a different level --> not possible with sessions since people do 
not want to have those 'stolen' by design)


this can result in so called 3rd party assisted fill-in of forms 
(in your example: suppose the guy on the phone can also assist 
someone that is actively filling in his form on the web but 
decides to call in for help and some questions: the operator 
could just complete the 'instance' (possibly more then one form 
in a more complex flow) and then says: please press refesh to see 
my updates)


> Just my 0.02 GBP/Euro/USD (depending on whatever country you're in)

nothing more then my .02 added

> 
>     Pier
> 

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org