cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Flowmaps: the wrong approach (was Re: [RT] (long) Rethinking Finite State Machine Approach to Flow Management)
Date Sat, 01 Dec 2001 20:18:17 GMT
On Sat, 01 Dec 2001 14:54:51 +0100, Stefano Mazzocchi <> wrote:

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

You ought to fill in the hole fairly quick ;-) It's too much power you
don't want to miss.

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

No, I think you get this wrong because you don't understand what
continuations are. Please read the following before discussing any

If you're not familiar with Scheme, it may be worthwhile starting to
read the document from the beginning:

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

My point with the example above was that you design your application
centered around your logic, not around your pages. You no longer have
to think in terms of events, but in terms of the logic of your
program. The while loop expresses the fact that you don't allow the
logic to proceed further until all the information was passed right.
In Scheme it would be possible to define a higher level abstraction,
by extending the syntax to introduce required arguments:

    until (username, password) are present

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

I'm not fooling myself, you can do this. Please read the first paper I
pointed you to in the last message.

When the user clicks three times the back button, and presses the
Submit button, he will send to the server an URL that identifies a
continuation object of a place in the program already visited. The
program resumes exactly in the same point!

This is possible because continuations are first-class objects in the
language. You can obtain them and put them in a hash table indexed by
an URL. When an URL is invoked, your server-side program looks up the
continuation in the hash table, and invokes the continuation
object. This will resume the execution of the program in the place
associated with that continuation.

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

This is possible by simply removing the continuation from the hash
table. The program can be thought this way and whenever you want to
disallow going back in the processing, you simply deactivate the

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

You think in terms of events and transitions, because you have the FSM
in mind. Free yourself from these abstractions and read about the
concepts I described. You'll find much more powerful concepts.

Using them you solve exactly the problems you mention, but in a very
procedural way for the programmer of the application.

> > 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:
> > 
> >
> > 
> > A Scheme interpreter written in Java, which implements the
> > abstractions in the above paper:
> > 
> >
> > 
> > Another paper that describes the concepts, and shows another
> > interesting possible implementation:
> > 
> >
> > 
> > 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:
> > 
> >
> That's great information. Thanks. I'll digest it right away and report
> back.

Please do.

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

No, no, you got me wrong. We don't need a 'statemap' either, instead
we need to rethink the concepts a bit. Let me explain.

I now believe we should have a system centered around logic, not
around states and transitions. The logic should be expressed in a
language that supports continuations. The logic should drive what
pages are presented to the user. These pages could be expressed in an
XML markup language with appropriate elements for extracting data
previously created in the program. These XML pages could be then
processed through a pipeline, similarly with how they are processed
today in the sitemap. However since incoming URLs are handled directly
by the logic, there's no need for matchers in the sitemap.

 HTTP request                         transformations
--------------> logic -----> XML page -----------------> HTML/WML/... page

The generated pages contain URLs that point back to continuation
points in the logic.

The biggest problem is the fact that the logic needs to be expressed
in language that supports continuations. Since most people don't like
the Lisp syntax, a language that abstracts out the continuations in
higher level abstractions like send-response could be developed. This
can probably be done by extending a familiar language, like
Javascript, with these concepts. The system would look like this:

               |         |      
               |  Java   |        
               | engine  |      
   HTTP     |              |             |
<-----------|  extended    |             |
  response  | Javascript   |             |
            |   engine     |             |
   HTTP     | (interpreted |             |
----------->|  in Scheme)  |             |
 request    | _____________|             |
            |                            |
            |                 Scheme     |
            |                 engine     |

The logic is essentially driven by a Javascript program, which has
higher-level extensions for interrupting the execution of the program
using continuations. The heavy-duty code, connecting to databases,
doing more complex logic, could be written in Java, and invoked from
the Javascript layer.

Oh, by the way, feel free to replace Javascript with any language you
like, perhaps even Java, as the language to write the direct
continuation style program that drives the Web application. I would
probably use Scheme directly ;-)

This is a huge paradigm shift from what we have right now, but I
believe leads to easier ways to write Web applications. They become
more like usual programs, instead of the complex beasts that we have
today, with state scattered all over the place in the code.

And yes, please read the papers I pointed to in my previous email, to
understand what the heck I'm talking about. Here they are for your

Best regards,
Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message