I went thru the recent "[RT] Generalizing the flow" thread and I want to give my impressions on it.
First of all, let me remind you that we agreed (for the FOM, but I think the vote can be applied to anything) on the general design principle that "less is more": start small and add things *only* when needed.
This is exactly the opposite of behavioral abstraction: provide an abstraction and free the people to implement their own in order to avoid having to reach consensus.
Polymorphism is a great technical concept, but it's an incredibly poor community tool: it creates balkanization.
The Avalon people know very well what I'm talking about.
Sylvain and Marc are proposing that we create an abstraction for flow control, stating that a continuation-based implementation is just one of the particular possible implemenations.
If you read my original RT about flowmaps (written two years ago), I was wondering exactly this: what is the *best* way of describing the flow of a web application in a way that keeps it centralized in one location?
There is no single answer. Just like turing completeness doesn't stop new programming languages to emerge.
You missed the point that was raised by the RT : the abstractions are already there. These are "Interpreter" and "WebContinuation". What the RT states is that these abstractions are actually wrongly named (what does the "Interpreter" concept have to do with page flow?), and thus lead to confusion of the underlying concepts to flow management and drive people that want to *integrate* (more on this word later) existing tools in a wrong direction.
Also, the comparison with Avalon doesn't seem good to me. What happened there is that new one-man code bases were developped in parallel in the same CVS repository. That's not what I want.
- o -
I learned programming at the age of 8, writing BASIC on a Commodore Vic20. I did BASIC until high school when, at the age of 13, I was *forced* to learn Pascal.
First thing I asked after being introduced to the language: if there are no explicit line numbers, how do you know where to "goto"? Answer: you don't, you don't need to.
What?
It was *impossible* for me to concieve a programming language without gotos. I didn't know that it was such a common misconception that it took decades for computer scientists to realize it was not the case. (until Edsger Dijkstra made it evident in 1968).
After Pascal, I moved into C, then x86 assembly code, where I went back to direct jumps, and hating it. It took me some 8 years to fully understand why gotos are harmful. And that was as I was a teenager and my mental flexibility was at maximum.
Will I be able to do the same now? how much time would that take me?
I'm sorry Stefano, but I can't believe the above. You're one of the most brilliant minds I've been given to know (even if not IRL now), able to invent so powerful and innovative concepts, able to build so many communities. So I can't believe you weren't able to grasp quickly the good things provided by new languages.
I had similar experiences to yours, changing languages and paradigms, but each one was a positive revelation and a succession of wow's. I moved from assembler to Basic, Pascal (not forced !), Lisp, object extensions to Lisp, Prolog, then (entering professional time) C, Ada, C++ and Java. Each new language came with its set of new concepts and paradigms, and I learned and used them with great pleasure and interest.
- o -
Marc is advocating that "there is more than just continuation-based flow control" and he is dead right: there are as many ways to implement flow control as there are stars in the sky.
But there are two major families of approaches: procedural vs. declarative.
The continuation-based flow is procedural. What Marc is proposing in his wiki page is declerative. state oriented. in short, it's a FSM. it's the "goto" equivalent for the web.
I'm sorry, but I cannot stop considering this harmful. or, at least, a poor substitute (for this kind of usage) for what we achieved with continuation-based produceral flow descriptions.
- o -
I understand Marc has a FSM-based controller already in place and wants to use it as a flow controller. I think that a few lines of javascript will do the job perfectly, or he can still keep using actions as he's doing right now.
- o -
Sylvain likes abstactions. Otherwise the sitemap interpreter would be called SitemapInterpreter instead of TreeProcessor.
Yes, I love abstractions. One of my goals when writing software is "zen design" (read the quote in my weblog's header), and abstractions are key for that.
But in the particular case of the TreeProcessor : I wrote it because we were discussing flowmaps, or alternate ways to write the sitemap (I remember Berin's RT about URI mappings), and I had the feeling experimentation was hindered by the fact that the compiled engine was difficult to do these experiments. So the TreeProcessor was a way to implement the Processor interface (the main Cocoon entry point) using an XML-based declarative approach, the sitemap language being one of the possible ways to do it.
I used to love abstractions as well.
Now I'm far more concerned about them: less is more.
A good abstraction doesn't prevent the "less is more" paradigm. Or is it because abstractions allow multiple implementations ? If that is the case, let me tell you that I disagree. Cocoon wouldn't be what it is today if it wasn't based on a few core abstractions with multiple implementations. Sure, this led to having too many implementations in some areas (but IMO not in the core), but also encouraged innovations and new features.
Cocoon is powerful because there is *ONE* sitemap semantics and my continuous obstructionism to the pluggability of sitemap semantics forced discussions to happen, that created community and focused development.
I can't remember of either people wanting to revolutionize the sitemap neither from you vetoing changes (because noone proposed some !). Why so ? Certainly because the sitemap is a concept that is unique to Cocoon. Application flow is not. It has existed as soon as people started to chain windows on a screen, and often depicted as an area where Cocoon isn't good compared to what already exist.
And we're here in the real meat of the RT : we don't want to have several competing implementations of the flow in Cocoon. We don't want balkanization. What we want is for Cocoon to provide it's own innovative solution (continuation-based flow), but at the same time be able to *integrate* other flow handling technologies.
You must think of it as the JSPGenerator and the JSPReader. Why use JSP in Cocoon when we have these powerful XML pipelines, XSP, etc ? Simply because we're not alone in the world, and because other people want to use Cocoon, but don't want to trash all what they know and did for that.
When Ovidiu started all this flow thing, I was enthusiastic about it. And I'm still. This continuation stuff is tremedously powerful and I love it. Note also, that all this wouldn't have been possible without the sitemap pluggability. Because yes, it _is_ pluggable : there has been a flow-enabled TreeProcessor configuration in the scratchpad for a very long time ;-)
Now, part of my job is giving Cocoon presentations and trainings, so I also talk about flowscript, continuation trees, the end of back-button infamy, etc. I always have a low of wow's and people find this very interesting.
And then, there are two categories of people :
- those who have no existing background on page flow problems. They have no problems with our way of doing it.
- those who have some background, either as code or as trained people.
People in the second category, after the mind blow is finished, ask me :
- "why use JavaScript ? I'm used to plain Java and don't want JavaScript".
- "I have an existing backend" or "I use Struts". "How can I link it to the flow ?"
What should I say ? Use actions ? Use Struts as the toplevel servlet and Cocoon for the view (I did this once) ? That's not satisfactory, because Cocoon will stay a auxiliary tool in their toolbox and they won't be able to use it to its full power.
Now what if we tell them "continuations-JS is the preferred and most powerful way, but if you want it, Struts (or other existing tools) fits nicely using the StrutsFlowEngine" ? We allow them to smoothly move to Cocoon concepts. And instead of trashing the flow once for all, they will use Cocoon+Struts on the first project, then flowscript on the second.
The sitemap and the flow are the core of Cocoon. Abstracting them will balkanize the cocoon community.
This comes to the real question : what's the "core" part of the flow ? Is it <map:flow> and <map:call>, or is it also the JS implementation ? If so, why do we already have another implementation (ATCT), when no one has ever written an alternate sitemap implementation ?
Also, what's the real difference between <map:call function=""> and <map:act type="call-function" src=""> ? Not that much, actually. Flow is just a particular set of actions that _have to_ end with an internal redirect.
I'm *strongly* -1 to anything that will go in this direction.
I'm *strongly* +1 to anything that will force discussion and improve the existing ideas (as we did with the sitemap semantics over the years and as we did with the FOM recently).
IMO, the FOM is not about semantics, but about defining those parts in the object model that we consider as "safe" for use in the flow by restricting the JS mapping of existing Java objects. Now imagine we had continuations in Java : would we have restricted e.g. the Request interface ? I'm not sure. Actually I don't think so.
The flow semantic is in <map:flow> and <map:call>. JS is "just" a programming language, and has no flow-related semantics except sendPageAndWait() that we added.
E pluribus unum.
Sorry, I haven't learned latin :-/
NOTE: my not-so-secret agenda is to keep the cocoon community as strong and unified as possible. This is my top priority, even higher than technical excellence or elegance.
Still, I see nothing excellent in going back to FSM-based flow control.
What it's all about is integration of *existing* flow implementations.
Forget about the particular FSM. Forget about the Wiki page that dumps the results of some wild discussions. Note however how Marc and I care for the community : we wanted this to be public quickly so that people could react to this, and eventually join the discussion.
Note also that, in the discussion following the RT, a number of people (most of them actually), thought that renaming the classes was making sense.
I agree that flow control is a more general than continuation-based flow control, exactly like sitemap is a much more general concept than "the current cocoon 2.1 sitemap semantics" (which is just an instance of that concept).
We choose one direction for our core and we keep evolving that. No polymorphism just because a few people have legacy they want to reuse, it's not our problem.
It *is* our problem. Again, I'm +1000 to have a single "official" flow implementation in Cocoon. But we can't ignore solutions people have developped in the outside world. Or we loose them for Cocoon.
Yeah, the next thing to unify will have to be the form handling. XMLForm and JXForm will be shortly unified. Hopefully, Woody will be as well.
Currently investigating in this area also...
Balkanization is the problem. FS is the signal. Community fragementation is the danger, expecially when blocks will be there.
So, instead of routing around consensus, let's work toward it, that means: no abstraction for core parts.
"No abstractions for core parts" ? Then Cocoon is dead. Or at least the Cocoon I love so much. Remember that it's because the Processor interface was abstracted that we have the TreeProcessor today, and maybe also the flow, because Ovidiu was able to play with it without impacting the core.
Sylvain
PS: I'm on vacation, so don't expect instant replies !
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
