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 18:39:48 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 ;-)
>>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)

It works like a charm !

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

Sorry, I don't clearly see what you mean here.

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

There may be no need for sessions with continuations, as the program 
state can be kept in the continuation.

An example where sessions aren't mandatory is the XMLForm integration : 
the form data is kept in the form object, which is a local variable of 
the script, and hence held by the continuation. This still allows to 
keep the value input in a screen when you go back, since the form 
_content_ changes, but not the form object itself.

So yes, there's a real-life reason for continuations without sessions. 
But clustering considerations (see above), make me think that the 
infrastructure requires us to bind continuations to sessions.

Things are also different with cocoon.createSession(), which binds 
global variables of the JS script to the session. This actually makes 
many flow scripts useless without a session.

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

That's exactly the concern I was expressing. Note however that bounding 
continuations to sessions will allow us to use load-balancing, but may 
still prevent the use of fail-over, which requires the session 
attributes to be serializable.

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

Are you really talking seriously about patching the load-balancing 
software, even of OSS servers ? This is way out of concern for Cocoon !

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

Definitely. And an additional lookup in the session attributes doesn't 
cost that much.

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

+1. This will also strengthen the expiration of continuations, as all 
continuations bound to a session will automatically disappear when the 
session terminates.


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

View raw message