You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2001/12/01 14:54:51 UTC
Re: Flowmaps: the wrong approach (was Re: [RT] (long) Rethinking Finite
State Machine Approach to Flow Management)
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Flowmaps: the wrong approach (was Re: [RT] (long) Rethinking Finite State Machine Approach to Flow Management)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 03.Dec.2001 -- 04:29 PM, Stefano Mazzocchi wrote:
> Christian Haul wrote:
> > I think a Flowmap will not ease the maintenance a lot because a FSM is
> > a highly complex graph and whatever you do, an XML file can only
> > describe tree structures well. Hence, again, things start spreading
> > around. The only solution I see, is to describe single states and all
> > transitions available from that point on, depth 1. And that is exactly
> > what the sitemap is today.
> >
> > In my opinion two things would be very cool: 1) the ability to use
> > macros in sitemap i.e. abilitiy to use XSLT prior to sitemap parsing
> > or (XSP would have some benifits, too, but I don't think it's worth
> > the effort)
>
> The experience of stylebook tells us that if we start down this path,
> pretty soon people will know the "simplified markup" and forget the
> power of the sitemap (people don't even know stylebook has a sitemap
> underneath that is generated transforming the book descriptors!). Of
> course, nothing stops you from using your own markup and your own
> transformation to come up with the sitemap but I would be against making
> it easier for users to do this automatically.
Sure enough. I still think it would improve readability. Anyway, it is
a big difference doing this transformation outside or automatically by
cocoon. AFAIC action-sets and resources are only a basic replacement
for such preprocessing.
> > 2) integrate some tool for FSM modelling. Most likely, (2)
> > is for free if (1) is in place and we find some tool that writes XML
> > FSMs.
>
> It's wrong to state that since XML is a tree, it can't describe graphs
> well. Example:
>
> <function name="a">
> <call function="a"/>
> </function>
>
> which is a tree describing a graph, once we have described what is the
> behavior associated with the semantics.
Granted. Although I expected you to come up with @ID and @IDREF :-)
Still, we might have different opinions on "well". And it's not only
because XML is a tree, but as well because it's 1 dimensional. SVG can
handle complex graphs -- but at least I don't want to create or modify
them in vi. I think, the current sitemap does a good job, but I doubt
whether separating it in a map for states and one for transitions will
do any good.
IMHO transisions are best declared for the state they
start. Transitions that are applicable to more than one state are best
declared for a complex state which is currently handled by nesting (or
mounting) of pipelines. Defining transitions at destination states as
well would make maintenance difficult, unless a tools supports this.
What this whole RT didn't touch is, in which ways a flowmap could
serve to create a menu (like) navigation. Although I fear that is too
complex to handle :-(
> So, IMHO, the best goal is to try to increase sitemap semantics in order
> to make it possible to describe both pipelines and flows, and let them
> interact easily.
Agreed. And I think, it's not much that's missing.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Flowmaps: the wrong approach (was Re: [RT] (long) Rethinking Finite
State Machine Approach to Flow Management)
Posted by Stefano Mazzocchi <st...@apache.org>.
Christian Haul wrote:
>
> On 01.Dec.2001 -- 02:54 PM, Stefano Mazzocchi wrote:
> > Ovidiu Predescu wrote:
> > 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.
>
> I'd like to second this oppinion, continuations look cool. OTOH will
> that scale? There are many around that don't like sessions because
> they require the server to devote memory for every session. OK, only
> *applications* would use them, so that's propably all right.
Yes. This is my other argument about turning the sitemap into a
procedural logic: all those published resources that don't need to
retain state are much easier to express with declarative languages (such
as current sitemap).
Also, I have the impression that even in complex web applications,
continuations are required only when performing a data entry that
requires subsequent screens and should not be required thruout the
entire webapp.
> > 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.
>
> I think the sitemap as a representation of a FSM is quite OK. Once you
> start matching on other things than URIs (e.g. session attributes or
> referer header i.e. your *current* state in addition to the requested
> transition), all aspects of an FSM can be modelled.
>
> I think a Flowmap will not ease the maintenance a lot because a FSM is
> a highly complex graph and whatever you do, an XML file can only
> describe tree structures well. Hence, again, things start spreading
> around. The only solution I see, is to describe single states and all
> transitions available from that point on, depth 1. And that is exactly
> what the sitemap is today.
>
> In my opinion two things would be very cool: 1) the ability to use
> macros in sitemap i.e. abilitiy to use XSLT prior to sitemap parsing
> or (XSP would have some benifits, too, but I don't think it's worth
> the effort)
The experience of stylebook tells us that if we start down this path,
pretty soon people will know the "simplified markup" and forget the
power of the sitemap (people don't even know stylebook has a sitemap
underneath that is generated transforming the book descriptors!). Of
course, nothing stops you from using your own markup and your own
transformation to come up with the sitemap but I would be against making
it easier for users to do this automatically.
> 2) integrate some tool for FSM modelling. Most likely, (2)
> is for free if (1) is in place and we find some tool that writes XML
> FSMs.
It's wrong to state that since XML is a tree, it can't describe graphs
well. Example:
<function name="a">
<call function="a"/>
</function>
which is a tree describing a graph, once we have described what is the
behavior associated with the semantics.
XML syntax is not that different from Lisp syntax. Admittedly, A little
too many paranthesis, but even if xml is more verbose, is much more
readable (because the ending paranthesis contains the content of what is
ending, unlike Lisp).
In fact, in Lisp, you can use the following syntax
(html (head (title "Dynamic HTML page in Lisp")) (body (h1 "hello
there!")))
once you have defined a shitload of macros one for each HTML element.
I like XML syntax better because:
1) it's easier to indent it.
2) it's easier to recognize a mistake (without an editing tool, Lisp
programming is impossible since you *always* loose parenthesis
somewhere! this is why Emacs was invented :) in fact, it's written in
Lisp because RMS was a big time Lisp programmer.
3) the ending parenthesis contains context on what is ends (some people
use this even in java, as comment after the closing curly brace, for
example
void doSomething() {
....
} // doSomething()
Look at the readability of XSLT (XML based) vs. DSSSL (Lisp based) and
you get an idea of what I mean.
So, please, XML is a poor syntax for semantically-dense programming
languages as much as Lisp is.
Admittedly, semantically driven char-based syntaxes like C/C++, Java,
Python, Perl, Ruby, etc.. are much less verbose (Perl is king for this)
since they "encode" programming language semantics sometimes into single
characters (unlike Lisp and XML).
But they are generally much less self-descripting (again, Perl is king
in lack of self-descriptiveness), which results in higher maintenance
costs for the code.
At the same time, as in different Lisp dialects, it's good to minimize
the amount of semantics required to fully describe the programmatic
logic.
In this sense, XML stands to SGML as Scheme stands to Lisp (more or
less).
So, IMHO, the best goal is to try to increase sitemap semantics in order
to make it possible to describe both pipelines and flows, and let them
interact easily.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Flowmaps: the wrong approach (was Re: [RT] (long) Rethinking Finite State Machine Approach to Flow Management)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 01.Dec.2001 -- 02:54 PM, Stefano Mazzocchi wrote:
> Ovidiu Predescu wrote:
> 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.
I'd like to second this oppinion, continuations look cool. OTOH will
that scale? There are many around that don't like sessions because
they require the server to devote memory for every session. OK, only
*applications* would use them, so that's propably all right.
> 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.
I think the sitemap as a representation of a FSM is quite OK. Once you
start matching on other things than URIs (e.g. session attributes or
referer header i.e. your *current* state in addition to the requested
transition), all aspects of an FSM can be modelled.
I think a Flowmap will not ease the maintenance a lot because a FSM is
a highly complex graph and whatever you do, an XML file can only
describe tree structures well. Hence, again, things start spreading
around. The only solution I see, is to describe single states and all
transitions available from that point on, depth 1. And that is exactly
what the sitemap is today.
In my opinion two things would be very cool: 1) the ability to use
macros in sitemap i.e. abilitiy to use XSLT prior to sitemap parsing
or (XSP would have some benifits, too, but I don't think it's worth
the effort) 2) integrate some tool for FSM modelling. Most likely, (2)
is for free if (1) is in place and we find some tool that writes XML
FSMs.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org