cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: SoC between flow and sitemap
Date Mon, 19 May 2003 21:13:25 GMT
Marc Portier wrote:

> Stefano Mazzocchi wrote:
>> on 5/18/03 4:53 PM Sylvain Wallez wrote:
>>> <historical-note>
>>> The TreeProcessor was written at a time where we were talking of 
>>> flowmaps, and we were thinking of writing it using an XML language. 
>>> The TreeProcessor is a framework for the defining the implementation 
>>> of Processor (the main Cocoon interface) in XML, using an 
>>> evaluation-tree based approach.
>>> The Ovidiu hacked those strange Scheme things in the scratchpad and 
>>> Chistopher added continuations to Rhino. And sitemap is very likely 
>>> to stay the only language implemented using the TreeProcessor ;-)
>>> </historical-note>
>>> So the important word in TreeProcessor is "Processor", which is the 
>>> interface this component implements.
>>> The same applies to the flow : in the view pipeline, we care about 
>>> data given by the flow controller, but don't care wether it's 
>>> written in JS, Scheme, continuation-enabled Java or stackless Python.
>>> So I don't see the problem of using the word "flow" in the object 
>>> model, as it is in no way related to the actual implementation of 
>>> the flow.
>> Gosh, you are right. In fact, the opposite is true: a "flow" is a 
>> basically a description of all state transitions of a FSM, without 
>> taking the states into account (which are included in the sitemap)
>> So, yeah, let's use "flow" to indicate that: the collection of all 
>> transitions in a FSM but without the states. Then FlowScript is the 
>> actual implementation of it (then PyFlow, JFlow and what not ;-)
> without the states?
> I thought the big thing would be to be able to restore full state 
> (stack and variables?)
> (just trying to understand, not perse challenging the name) 

No worries : reading this paragraph again after your remark, I also 
wonder what Stefano tries to explain. The flow script both holds the 
flow _and_ the state. The sitemap only defines the view.

>> <snip/>
>>> You cannot store the continuation ID in a cookie, as the cookie has 
>>> a single value for the entire browser session, both in time and 
>>> space (separate windows). The continuation ID *really must* be 
>>> transmitted by the request (either form values or part of the URI).
>> d'oh! you're right.
>>> This is only one of the reasons why fetching the continuation ID 
>>> cannot be hardcoded. Another example is the XMLForm integration with 
>>> the flow (yep, one more nice thing by Christopher!), where a single 
>>> page holds 2 continuations ID : the current one associated to 
>>> "next", and a previous one associated to "prev".
>> Yes. I remember discussing this IRL with Ugo a while back where he 
>> was exactly complaining about the fact that a "back" button 
>> associated with the previous continuation would simply make us fall 
>> back in the same screen we are, not in the previous one. And jumping 
>> back by two continuations will re-execute the logic between the two 
>> previous screens (which is not always desirable). Glad to see that 
>> fixed (I haven't tried it yet)
>> Note: wouldn't it be better to store one continuation ID, then add 
>> the "history" of continuations to the Continuation object that we 
>> retrieve with that ID?
> which would make things look more like the approach I was mentioning
> one id that points to the complete interaction, and in there possible 
> addressable sub-resources
> also, I find the ability to link to back and previous rather dull (in 
> fact I would of hoped that flow was the thing that worked out  the 
> browser back button?)  in real life I would see not only the old-style 
> wizard back/next/finish buttons but actually some random navigation 
> back to any previous screen you had in this interaction... 

It also works that way, and continuations have reference to their parent 
continuation (see o.a.c.c.flow.WebContinuation).

>>> So we really need to be able to extract continuation IDs in various 
>>> ways from the request. And the sitemap is IMO the best place to do 
>>> that.
>> I tend to agree.
>>> Now we could adapt the continuation naming schemes. Currently, we 
>>> have a single global naming space with long numbers to ensure 
>>> uniqueness and avoid "continuation hijacking". We could have a 
>>> simpler naming scheme for those continuations where the global 
>>> variable scope is tied to the session (using Cocoon.createSession). 
>>> This could even be a simple integer sequence, with an initial prefix 
>>> to differentiate them from global continuations. This would also 
>>> solve potential problems of the ContinuationsManager on clustered 
>>> servers.
>> Ricardo and I discussed extensively about this and started 
>> challenging the notion of continuations without sessions. Is there a 
>> real-life reason for them?
> sessions are limited in the sense that they have the habbit of making 
> 'singeltons' per session of the objects you store in there... sessions 
> are also tied to a single end-user
> so using sessions limits you.
> while you often may want that, it doesn't seem to be a general case to 
> me.

Continuations allow different behaviours : as local variables are bound 
to the continuation (and not the session), a flow script using only 
local variables avoids this singleton limitation. You can use global 
script variables (bound to the session) for items that really are 
singletons in the user space, such as user name and credentials.

>> I tend to see it very dangerous to change the behavior of the flow 
>> engine depending on the existance of the session. It's implicit, it's 
>> transparent, it's hidden. users will be hurt by this and will become 
>> best practice to instantiate a session right away every time but I 
>> see no reasons for this
> you lost me here 

I guess this means "having different continuation naming schemes between 
session-bound and not session-bound continuations is not a good thing".

>> note that sessions are very lightweight objects per-se and sessions 
>> provide transparent load-balancing capabilities that are not matched 
>> by clusters. For example, if you have a clustered cocoon environment 
>> and you use continuations without sessions, your request might be 
>> sent to a cocoon different from the one your previous response came 
>> from, generating an undefined state or, more likely, an "invalid 
>> continuation" error.
>> to avoid this, either we make the different clustered cocoon exchange 
>> continuations over the wire (bottleneck!) or we patch the 
>> load-balancing software to take continuation into consideration! (but 
>> since there is no general rule, you have to patch it by yourself 
>> everytime and most of the time, in big webapp servers like weblogic 
>> or websphere you don't even have access to it!)
>> understand that horizontal scalability is *much* more important than 
>> raw cocoon speed  and we must make all possible efforts to allow this 
>> to happen or cocoon will never make it on really loaded sites.
>> So, what do you think if we dropped sessions-less continuations 
>> alltogether and have the flow engine transparently create a session 
>> for you in all cases?
> not sure if I understand all depths yet, but it seems to limit me 
> quite a bit 

The only limit it gives is that you won't be able to share continuations 
between sessions. A use of data shared between sessions is your example 
of call center, but I'm not sure implementing this by sharing 
continuations is a good thing, since a continuation not only represents 
a resource state, but a program state.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message