cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
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:
> 
> 
>><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)

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

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


Mime
View raw message