cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Less is More, Finite State Machines and Balkanization
Date Sun, 13 Jul 2003 17:56:38 GMT
I like this thread. It might seem a little 'accademic' to talk about  
all these things so openly and, for sure, many of these things tend to  
be rather subjective, thus harder to find rational consensus on.

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  

> 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  

> 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  

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

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


View raw message