Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C08E12B.2D3A6F5F@apache.org>
Date: Sat, 01 Dec 2001 14:54:51 +0100
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Flowmaps: the wrong approach (was Re: [RT] (long) Rethinking
 Finite
 State Machine Approach to Flow Management)
References: <200111302238.fAUMcku06992@orion.rgv.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ovidiu Predescu wrote:
> 
> This is very interesting, in the past few weeks I was investigating
> alternative approaches to FSM too!

This is getting interesting. Talking about distributed IQ :)

> What I was looking at were continuations in functional languages like
> Scheme. 

Uh, gosh, I find myself with no info on this... how is that possible? :)

> With their aid you can essentially describe a very complex Web
> based interaction just like when you're writing in a procedural
> language. It's amazingly simple and powerful!

Ok
 
> For example, you can write a login sequence like this (pseudo-code,
> not actual Scheme syntax):
> 
> void login()
> {
>   page = "login.xml"
> 
>   while (true) {
>     send-response (page)
>     username = getParameter ("username")
>     password = getParameter ("password")
>     if (username, password) in database
>       break
>     page = "bad-login.xml"
>   }
> 
>   compose-news()
> }
> 
> void compose-news ()
> {
>   // Display the news composing form
>   page = "compose-news.xml"
>   while (true) {
>     send-response (page)
>     subject = getParameter ("subject")
>     body = getParameter ("body")
>     if (subject == null)
>       page = "no-subject.xml"
>     else if (body == null)
>       page = "no-body.xml"
>     else
>       break
>   }
> 
>   // Do some other stuff here
> }

<thinking-out-loud>

hmmmm, hmmmm, hmmmm... 

I like the concept of "continuations". Sitemaps are completely
declarative and for this reason they don't provide a simple way to
perceive the "flow" between stages.

Flowmaps would be the opposite: visualize flow, but fail to provide
information on stages. In some senses, they provide a way to express
"continuations" of client-server transitions.

The "statemap" concept should bring the two things together. How that is
possible is yet to be identified even if there are some general
guidelines (Giacomo, I think we can throw in our RT now)

I've seen the XML syntax and the Scheme syntax compared a lot... here
Ovidiu tells me that since flows are normally created by programmers
(and I think this is normally true), they should write it as a
programming language.

Whether using the scheme or XML syntax is yet to be seen.

So, in all honesty, I don't see a big difference between what Ovidiu is
presenting (rather than giving better names and more references to the
same concepts in other programming languages, which is indeed a good
thing) and what I was thinking before.

Yes, the flowmap alone would be kind of useless since it would be biased
toward flow and fail to describe states. Just like the sitemap describes
states but fails to describe transitions.

The statemap should bring the two world together. What syntax we use to
express it, is not something I'm really concerned at this point.

</thinking-out-loud>
 
> In the above example send-response is a special procedure, which sends
> the response back to the client, saves the state of the program in a
> so-called continuation object, and stops the execution of the thread
> serving the request, simply killing it.
> 
> When the client clicks the "Submit" button on the displayed HTML page,
> the program is awaken by the system _exactly_ where it stopped, and
> continues the execution as it wasn't interrupted at all!

Yes. This what we should aim to achieve: client-server transitions are
'transport-level' from our point of view. We should be able to describe
our application without knowing caring about how granular the data
transport is.

At the same time, we must not fail to understand that sometimes
framework design is imposed by the usage of the application: for
example, GUI design is inherently declarative, thus event driven.

What I don't like in your approach is the use of while(true) {}
statements, something that rings bells in my mind about using a
procedural design for something that is and remains event driven, thus
is should be declarative.

> Even more, this mechanism takes care of the situation where the user
> uses the back button to view some older pages, and then decides to
> continue on an alternative path. Since the continuation objects are
> still maintained by the system, hitting the submit button in such a
> page will resume the program in a previous point in its execution!

C'mon, don't fool yourself: you can't avoid the user to click the back
button three times and the restart from there. You won't have the
information of those three 'back' clicks. Your procedural "continuation"
works if you *always* have the information on what state you are in,
unfortunately, due to the intrinsic statelessness HTTP design, you can't
have that.
 
> In some cases though, you don't want to allow such behaviors. There
> are ways through which you can nullify the past continuations, and
> remove them from the system. This will disallow the user to go back
> and go on alternate paths.

I'm sorry but I don't see how this can be possible.
 
> With this mechanism you can write Web apps which are a _lot_ easier to
> write, maintain, and validate as correct. All the logic is expressed
> in a natural way to the programmer, as procedures. In fact some of the
> more complex Web applications are very hard to write using FSM, simply
> because they cannot be expressed using a regular grammar.

Sorry, but I don't buy this: it's true that FSM programming gets messy
and hard, but there are cases (see the back button above) where you
can't programmatically know that a transition took place, so either you
have a 'back-aware' continuation mechanism underneath your procedural
language (which might or might not be possible, I don't know) or you end
up mixing procedural definitions of transitions and declarative entry
points.

Which is not intrinsically bad since the sitemap itself is designed like
this. Or GUI systems.
 
> Unfortunately continuations are something specific to functional
> languages, Java doesn't support this concept. Fortunately there is a
> whole theory (Continuation Passing Style, do a search on Google for
> more info) on how to take a continuation style program and transform
> it into a program for a language without continuations.

Oh, I'm sure it's possible.
 
> Here are some very useful resources that describe in detail the
> concepts I mentioned above:
> 
> The original paper describing the relationship between Web and
> continuations:
> 
>   http://youpou.lip6.fr/queinnec/Papers/webcont.ps.gz
> 
> A Scheme interpreter written in Java, which implements the
> abstractions in the above paper:
> 
>   http://youpou.lip6.fr/queinnec/VideoC/ps3i.html
> 
> Another paper that describes the concepts, and shows another
> interesting possible implementation:
> 
>   http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.ps.gz
> 
> The last paper shows some very impressive figures. Although I wasn't
> quite able to obtain the same performances as described above, I still
> got very good results.
> 
> And here is a paper, which while not showing any of the above,
> explains why would one want to program in Lisp :-) The author wrote
> together with another guy a Web app in early 1995, which sold to Yahoo
> in 1997, and is currently Yahoo Store, for $50 million I'm told. The
> site is written entirely in Lisp! Check it out at:
> 
> http://www.paulgraham.com/avg.html

That's great information. Thanks. I'll digest it right away and report
back.

For now, let me state a couple of points:

1) sitemaps define states but fail to express transitions between these
states. 

The Cocoon1 reactor patter mixed both states and transitions. The
sitemap improves the model by centralizing state information. But
transition information is still scattered around the entire application,
preventing ease of coding/maintenance and reusability.

2) so, next goal is to come up with something that improves on that
model by centralizing both state and transition information. hopefully
in a reusable way.

3) I call this concept "statemap". A "statemap" is made up of one or
more "sitemaps" that describe states and one or more "flowmaps" that
describe transitions.

As Ovidiu states in the subject, turning sitemaps into flowmaps is wrong
as it doesn't solve the problem: it would centralize transitions but
scatter state information.

We need something more general.

4) Whether the 'statemap' should be implemented as a description of a
full FSM or with some other semantics/syntax, it's still not something
that concerns me.

Giacomo and I attacked the problem space from very high and tried to get
closer to the problem space.

I think it's now time to share our thoughts on this.

Giacomo, fire at will. :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org