On Tue, 11 Dec 2001, Stefano Mazzocchi wrote:
> Ovidiu Predescu wrote:
> >
<snipped a big chunck of information/>
> Yes, I had the taste of the power of continuations when I dived more
> into the paper you presented (and implemented myself a few scheme
> examples to get the feeling of it).
I do like the concept of continuation as well. It gives you a better way
of writing interactive apps. It's like in the early days of programming
where you had stuff like this:
write "prompt >"
read answer
if answer is correct
do it
else
redo
> I think we *do* have very interesting functionality here that would
> finally remove the obstacles the stateless web model forced us on.
>
> I do see, now, why a FSM approach is probably not the best approach.
>
> > > The concept of "continuations" while a flexible and powerful concept must
> > > come to grips with the concept of branching flows--which I do not think
> > > it does.
> > >
> > > I think that full FSM terminology is overkill, and would only serve to
> > > frighten newbies. However, digging through the archives, I came up with
> > > a concept that would also work:
> > >
> > > <flow name="addNumbers" start="first-page">
> > > <resource name="first-page">
> > > <pipeline type="my-pipeline" source="first-page.xml"/>
> > > <next name="second-page"/>
> > > </resource>
> > > <resource name="second-page">
> > > <action type="getFirst">
> > > <pipeline type="my-pipeline" source="second-page.xml"/>
> > > <next name="third-page"/>
> > > </action>
> > > <redirect-to resource="first-page"/>
> > > </resource>
> > > <resource name="third-page">
> > > <action type="getSecondResult">
> > > <pipeline type="my-pipeline" source="third-page.xml"/>
> > > <done/>
> > > </action>
> > > <redirect-to resource="second-page"/>
> > > </resource>
> > > </flow>
> > >
> > > This uses the same semantics for actions and provides the transitions,
> > > handling errors.
> >
> > I don't like the above semantic. The redirect functionality was
> > invented to alleviate the lack of continuing an interrupted processing
> > that can change the path in your program. I think there's no need for
> > it with the model I propose. Maybe I'm wrong, please show me if this
> > is the case.
>
> I find myself resonating with Ovidiu on this.
>
> The whole argument reminds me of the cognitive friction I had when
> abandoning BASIC GOTOs switching to Pascal.
>
> If this is so, the "GOTO considered harmful" decade-old anti-pattern
> could be well applied to web programming and explicit flow redirection,
> giving us a 'clear' metric to judge a web technology.
>
> In this case, Ovidiu's proposal is clearly better than Berin's.
>
> > Also I don't like to express logic in XML, it's not what it was
> > designed for. We need a programming language, so why use an XML syntax
> > to express this? The attempts to use XML to implement a programming
> > language are taking XML too far, where it wasn't designed to work.
>
> Granted.
>
> In fact, for flow-driving semantics, I'd far prefer a ECMAScript-like
> syntax because it would be
>
> a) less verbose than XML
Verbosity isn't always bad (even in the programming concern). If you can
force some verbosity it can make things look much clearer. I remember
reading books from famous people like Niklaus Wirth where variables in
his samples where single letter names :(. XML elements and attribute can
force you to use verbose names which is a huge win IMO.
> b) generally more readable (consider escaping <,>,& or using CDATA)
To be honest, IMO this isn't a big issue. You can always choose
alternatives as many popular languages are using like lt, gt, and, etc.
(which makes them even more readable).
> c) easier to learn/use/understand for C/C++/C#/Java/JavaScript people
> (a very big percentage of the web tech population nowadays)
The "web tech population nowadays" understand HTML as well so this can't
be an issue.
> At the same time, for global site-mapping semantics, the XML syntax is
> still the way to go.
This is a big +1 for me. After seeing the way how Ovidiu's proposals in
the scatchpad area defines pipelines in a Scheme/Lisp syntax I strongly
propose to stay with what we have in the sitemap today. The introduction
of map:call elements into the sitemap and the proposals from Berin
to separate pipeline definitions from mapping show
IMO a clear way where to go.
> > --
> >
> > I think with the new model, there's no need for actions, redirects and
> > other things that the sitemap currently has.
>
> Yes, I've always expressed my feeling that Actions were hacks.
:) They aren't hacks, the are only in the wrong context because of lack
of alternative places to place them.
Redirection was introduced to reduce frition to visitors when web
masters had to reorganize their sites. Nowadays web programmers use it
as a natural *feature* for web programming (which is as Stefano
mentioned somewhere similar to GOTO programming).
BTW this concept isn't new since servlets. I remember old days where one
wrote programs for the IMS/DC Online Transaction Monitor which had the
exact same approach (including mechanisms like servlet chaining but not
redirect as this isn't a feature character terminals had unlike
browsers)
> > They are no longer needed
> > as you have full control over what's going on in your application at
> > the program level. And you can control your application in a much
> > better way than before.
>
> Absolutely.
>
> > In the new model, the sitemap becomes a dispatcher to either a
> > pipeline, or to a function in our language with implicit continuations
> > (any good name for it?).
>
> I think you are oversimplifying: I agree with you that actions and
> action-sets are something that should not be in the sitemap (I always
> found strident the different degree of reuse you had with pipeline
> components and actions), but at the same time, the current sitemap
> semantics is IMO very well designed for stateless publishing needs,
> which still are the great majority of the web resources.
>
> > A pipeline describes how an input document should be transformed to
> > HTML/WML etc, and nothing else. No actions, no redirects, no
> > programming at the pipeline level.
>
> In fact, the name "sitemap" is exactly that: 'a map for the site'.
>
> When Pier and I designed the concept, we had the feeling that it was
> possible to separate the concer of 'mapping resources' and assembling
> the pipelines that generate them, from that of programming the flow
> between the different resources.
>
> Since we couldn't find an elegant way to add these capabilities (at that
> time, we were thinking about letting Turbine take care of that part!) we
> decided to postpone further design.
>
> Unfortunately, since flow-driving instructions are required even for the
> most simple restriction-based publishing system, the need for headless
> programmatic activity emerged, and the Turbine Action concept was ported
> over to Cocoon.
>
> Giacomo knows that I never really liked this approach, but I didn't stop
> the effort because I wasn't able to provide a more elegant solution.
I have to make this clear, I've choosen the scratchpad concept than and
was forced to move it to the main trunk by the community because of lack
of alternatives.
> Interesting enough, what you described in your above example is exactly
> the kind of 'flowmap' that I've been looking for in order to move away
> actions from the sitemap.
I have no objections to this :)
> I knew that the intrinsic 'wait for request' behavior of the site forces
> the sitemap to follow a declarative approach, as much as the 'drive the
> flow' behavior of a web application would force the flowmap to follow a
> more procedural approach.
Agreed.
> Even more: since the sitemap might be written by people used to publish
> information and documents, the XML syntax is more suited for their
> skillset. At the same time, since the flowmap is written by people used
> to write programming languages, a java-like syntax is better suited for
> their skillset.
Still not sure about that. XML can be easier parsed and validated and
thus forced to what ever we like it to be (concerning verbosity).
> In this vision, Berin's proposal to make pipelines reusable by adding
> variable substitution might allow both sitemap and flowmap to use sort
> these pipeline definitions (pipemaps?) and reduce overall verbosity.
Big +1.
> Anyway, I think that by trying to prove the Flowmap concept wrong,
> Ovidiu gave us the best example of a flowmap in terms of syntax
> (code-based instead of XML-based) and functionality (continuations-based
> instead of FSM-based).
code-based: +0
continuation-based: +1
> > If you need to describe logic, you do it using the language. This
> > describes which pages are sent in what order. When you want to
> > generate a result, you call send-page() with the source document, a
> > pipeline definition that should process your document, and additional
> > data to be used in generating the source page dynamically.
> >
> > To generate the source document, it's better if we use a markup
> > language that prevents users from doing computations in the page. The
> > page should be generated only from data passed to the pipeline by
> > send-page(). I haven't used it before, but Velocity seems to be a good
> > fit for this, as it doesn't allow any embedded processing in the page.
>
> Since Cocoon content will always be XML-ized, I see two possible
> solutions here:
>
> 1) use XML-orthogonal solutions (Velocity)
>
> <p>Today is ${date}</p>
-0 it mixes too much IMO.
> 2) use XML-namespaced solutions
+1 this is what XSP wanted to force.
> <p>Today is <dxml:date/></p>
>
> Again, the semantics are exactly the same, but the first approach if
> more friendly to code writers, the second to HTML writers. We could even
> have both and let the user decide which one he/she like the best.
FS
> > With this model we have the clear separation of concerns. Each layer
> > does only the things it's supposed to do, in a clean way.
>
> Absolutely:
>
> sitemap -> handles the stateless needs
> flowmap -> handles the statefull needs
pipemap -> handles the resources needed
> Add a simple and effective way to pass data from the *maps to the
> pipelines and into the content XML files and we are done.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
