cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: SoC between flow and sitemap
Date Mon, 19 May 2003 19:34:41 GMT

Stefano Mazzocchi wrote:
> on 5/18/03 4:53 PM Sylvain Wallez wrote:
>>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 ;-)
>>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)

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

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

> 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

> 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

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message