The result of this thread may not be an objective guideline, but I'm glad we are presenting different views and design strategies on the table because, at least, we know what other people feel about these things and we can forecast future friction and, hopefully, prevent it.
On Sunday, Jul 13, 2003, at 10:43 America/Guayaquil, Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
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.
There are many abstractions in Cocoon that shouldn't be there. This is what I call "overcomponentization". Making some that are somewhat hidden more visible, just because they were made there is not exactly a good pattern.
Just like namespaces were not coherent and unified, and now we require to nofity the community about the creation of a new namespace, I think abstractions should be discussed by the community, not just proposed by the single developer because he/she likes to code like that.
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.
I know you don't want this, but what effort are you making an effort to prevent it? (I'm not sarcastic, rather curious, since I might have missed something)
- 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'm bad at programming languages. Unlike many of you, I hate programming. I just consider it something that, sometimes, I have to do. I'm a visual thinker and computer languages were not designed with people like me in mind (or by people like me)
[btw, my visual mind is what stops me from learning Perl, and god, I tried!]
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.
I'm not saying that I didn't experience pleasure and interest. I'm just saying that it was not obvious to change paradigms and there is a human tendency to avoid paradigm changes and to stick to the known.
Some people are more open than others. I used to be very closed, conservative on my thinking. Open source and the ability to work with the most talented people in the world really changed my mind.
What you have come to know (even if only virtually) is not the 16-years-old myself. ;-)
- 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.
I see your point, but I'm not sure I resonate with this anymore. Bah, probably is my Avalon-induced paranoia that kicks in, but, god, I really find myself swinging from one side to the other with no control.
Hard stuff.
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.
This is true and I don't want to do anything that stops innovation.
But while there are areas where this kind of independent innovation does good (see all Chris' work in the scrachpad as an example, he did incredible stuff there all by himself and now it's becoming mainstream, moved into the trunk and backed up by several people. *THIS* is what I want), there are areas where this independent innovation might have just hurt (for example, if we allowed independent pluggable sitemaps)
Or, I might just be *absolutely* wrong and the reason why there are no pluggable sitemaps is because nobody really wanted them and there was no community reason for that.
I'm really confused now :-o
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 !).
I never vetoed anything, Sylvain. And I never will. My *strong* -1 reflects to my emotional attachments to the vote, not to the *weight* of that vote.
I hope this is clear: I dislike vetos. I think nobody should have the power to veto something.
Too bad the PMC didn't come up with the voting rules yet.
Why so ? Certainly because the sitemap is a concept that is unique to Cocoon. Application flow is not.
I agree and I disagree. The sitemap is somewhat similar to httpd.conf or web.xml, just more rationalized and more SoC driven.
Application flow is not unique to cocoon, but the way we separate concerns between resource generation and flow description is.
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.
the fact that cocoon wasn't good in those areas implies a limitation of the sitemap, not that other frameworks/solutions did a better job at separation those concerns.
what is unique to cocoon, generically, is how carefully SoC-based the overall design is kept and measured with those metrics.
With this vision, I agree that the proposed abstraction is not harming the SoC-based design.
My concern, at this stage, is how this abstraction-induced polymorphism is going to help the community.
Darwinistically speaking, I'm afraid the mutation rate induced by this change might be too high for the community to be able to digest it and converge to a unified solution.
At the same time, innovation (read: mutation) cannot be stopped or it's the end of evolution.
As Berin rightly notes, both a high mutation rate and a low mutation rate leads to extintion.
We will be injecting tons of mutation after Cocoon 2.1 is out. I'm afraid this might be too much, that's why I'm pushing on the break of mutation.
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.
I'm sorry, but I don't see the difference between "integrate" and "having multiple competing implementations". Can you elaborate more? this is probably really important.
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.
wait wait wait: if you are talking about connecting legacy stuff to the current flow handler, I'm sure you can do it in just a few lines of flowscript. Legacy connection is *not* a good point here.
As Leo said: instead of allowing multiple implementations *just because it's cool*, have people present their problems that can't be solved with the current implementation.
I haven't seen this happening. I've just seen arguments like "my customer doesn't want to write javascript" or "I'm used to state transisions and I like them more".
These arguments do reflect reality (granted), but they don't show a reason for abstraction and don't back up the dangers of increasing the mutation rate of our code so dramatically.
[NOTE: if your customer dislikes to write javascript, use something like BPEL4WS (http://www.oasis-open.org/committees/download.php/2046/BPEL%20V1- 1%20May%205%202003%20Final.pdf) and XSLT-transform it into flowscript using an internal pipeline in the <map:script src="">.]
My point is: absraction in some key areas might prevent discussion (like this one) and might prevent ideas to be exchanged (like the above, which might be totally damn or genial, I don't know [kudos to Chris to pointing me to BPEL4WS, BTW]
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 ;-)
I know it's already pluggable. My concerns have been there for a while, your proposal just triggered them.
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 ?"
See? this is what Leo was asking for: give us your *problems* and we'll cook together a solution. don't just work around the problem by allowing everybody to plug in their own solutions.
this approach is the one that makes it easy to create one-man-shows. a one-man-show for a sitemap component is admissible, because components are such small things, but one-man-show for a flow controller (or for a form handler, or for an entire block) those are the things that we must watch really carefully.
the form handling part is already creating community problems (see Ivelin's moves) and damaging the user perception on the long-term stability of the system.
Don't you find it interesting that the people who watched the avalon process closely are now backing me up in really reconsidering the influence of abstraction and polymorphism on community dynamics?
the (admittedly small) friction in the form-handling realm indicates that polymorphic innovation *must* be backed up with plans on how to aggregate the results into a single, unified and coherent solution that users can digest easily and, more important, trust long term.
I've said already that I have no problem if Marc or Peter implement their own control flow in the scratchpad to show us their solution, but *then* the community has to decide whether to:
1) replace the core flow control with those 2) integrate their solutions with the existing core flow control 3) discard the solution
Allowing different implementations of such a key piece of the framework to cohexist is simply going to harm us. Read: balkanization means fratricide wars. Just like Ivelin forking out and disappointing a bunch of people that trusted that code to be part of Cocoon and, more important, to be actively maintained in the future.
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.
Oh, man, you know we all agree to that. But is pluggable flow control *really* the best solution to this?
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.
I do see the marketing value of allowing an easy transision from other webapp frameworks to the newly webapp-ready Cocoon.
What I'm asking is just, as Leo, to work on a problem to create a solution thru community open development. Not to see it as an obstacle (or a trashing bulldozer) and find ways to route around it (as your proposal sounds like and Marc's repetitive personal attacks to my negative reaction seem to evidently imply).
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 ?
This is your really good point and made me swing back and forward during the writing of this reply.
I don't have an answer for this.
But I do have fears of one-man-shows. Probably paranoia, yeah. Probably personal attacks to negative technical comments don't make me forecast good community behavior. Or I'm being an asshole and I just see shadows where there aren't any.
I don't know.
but at least I wanted to show my concerns in all honesty with all of you.
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.
From a purely technical perspective, this is absolutely true.
From a perceptual perspective, flow was designed to centralized control in one location, actions where not. And their usage/abusage pattern reflects this
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.
I would have proposed so. It enforces best practicesa and "less is more" paradigm. Something that the servlet API lost long ago and I would like to see resurrected.
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.
Sylvain, look: I see no technical issues with your proposal, I'm just concerned on the community dynamics it might generate and I wanted to raise awareness.
The way I choose to do this is to force a little people to react to see how they did it.
I can't say I was happy about some people's reactions.
E pluribus unum.
Sorry, I haven't learned latin :-/
"from many, one" (the USA motto, BTW)
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.
I would have liked something like:
1) we want to integrate existing flow implementations (such as this and that)
2) we propose to do this, what do you guys think?
3) we accept disagreement and find consensus
Instead, the thing went like this:
1) we talked privately and would like to see this happening for this and that reason
2) people disagreed
3) personally attacks started
I have to be honest: I'm *very* worried by the reaction that some people tend to have toward disagreement on their proposals or visions.
No, this is not FUD. It's under your eyes. It's a fact.
Can we start over again (third time!) and work to find consensus on these issues?
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.
A discussion has to allow people to disagree without being named as "bulldozer drivers".
[yes, I keep citing this because that really pissed me off]
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.
if you think you have reached consensus, you are very welcome to ask for a vote. As I said, I will accept what the community decides. But I would like to be able to express my vote (whatever it is) without being personally questioned.
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.
Absolutely! What is *NOT* our problem is if those people want to have their way of doing it.
reminds me of the Rolling Stones song: you can't always get what you want, but sometimes, you get what you need.
I didn't see this approach to problems, just trying to find a way to allow personal solutions to be plugged in, routing around the community considered as an obstacle to personal innovation.
I can't stop finding this abusive.
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.
Ok, wrong wording. I take that back. Allow me to rephrase: I want the community to work toward consensus, not routing around it with increased polymorphism.
This doesn't stop innovation, but forced people to go thru the community so that control, coherence and feedback is maintained and the cocoon platform is not abused.
Hope my point is clearer now.
-- Stefano.
