cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: SoC between flow and sitemap
Date Mon, 19 May 2003 16:49:01 GMT
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 ;-)

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

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

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.

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?

-- 
Stefano.



Mime
View raw message