cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 19:59:00 GMT
[Going back from a one-day trip high in the sunny mountain]

Stefano Mazzocchi wrote:


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

Agree. That's why I proposed the changes instead of doing them righ away 
without asking. Note that renaming the classes underneath the flow is 
*totally transparent* to the FOM and to any flowscript.

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

Simple (simplistic ?) answer : allow other implementation to be 
developped elsewhere, and only accept them in the code base if these 
implementations have some community and real world usage (Apache project 
rules for blocks, as someone mentioned).


> [btw, my visual mind is what stops me from learning Perl, and god, I  
> tried!] 

I looked at Perl, and decided I didn't want to learn it ;-)


> What you have come to know (even if only virtually) is not the 
> 16-years-old myself. ;-) 

I'd like to have a time-warp machine ;-)


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

That's exactly my opinion : if there's no itch to scratch, nobody will 

> I'm really confused now :-o 

I can easily understand that.

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

Ok, "veto" was a too strong word. I dislike vetoes also : why should a 
single man be able to block community decisions ?

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

Is it really so unique ? My Struts knowledge is limited, but isn't this 
separation precisely the purpose of Strut's Forward class and one of its 
major marketing arguments ?

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

Marc and I deliberately separated the RT and the wiki page, with the 
respective purposes :

- the RT proposes some very limited renamings so that alternate 
implementations are possible without distorting the meaning of what we 
have in Cocoon's CVS. The proposal, in no way, is about having these 
alternate implementations in Cocoon's CVS.

- the wiki page is a dump of the exchanges Marc and I had on this 
subject, trying to show the range of the possible things. Most of its 
content can be qualified as "wild thoughts". By this, we mean thoughts 
that must be domesticated before then can be considered as "random". But 
we wanted to share this with the community, in order to know if this was 
itching others people as well.

So, once again : we do not want an FSM-based implementation. We just 
want other "foreign" implementations based on other technologies to be 
possible, by using the nice SoC introduced in the sitemap by the 
flow-related statement, and without having to use the all-purpose and 
no-meaning Action interface.

What is worse : allow alternate implementations to use the flow-relates 
SoC in the sitemap, or constrain them to use actions and thus completely 
neglect the nice SoC'ed infrastructure that we've set up ?

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

I think the key difference it the location of these implementations : 
"competing" means having them in the CVS, while allowing alternate 
implementations to "integrate" existing technologies doesn't mean they 
have to reside in Cocoon's CVS and therefore be officially endorsed by 
the project.

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

Sorry, but yes it is a good point : tell people that they have to go 
through some JS wrappers to call their Java code from a Java system. The 
will laugh and trash what they'll consider as a nuclear powerplant for 
so simple things !

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

If you go to the recent thread "[Vote] Cocoon Advanced Flow Control" 
(sorry, I'm offline so I can't provide you the link), you'll find this 
quote that I sent to Reinhard asking me about how to present the RT in 
the vote :
"The discussion following the RT showed that the proposed changes can 
conceptually make sense but require more thinking and some concrete code 
to be widely accepted. So we won't vote on this issue now, but this 
subject is very likely to come back in a more formalized form and with 
actual code in the future."

See ? Before you stepped in, I already considered the need for some more 
concrete meat.

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

Stefano, I'd like to go a bit on Marc's case. He is a kind guy, eager to 
learn, not opposed to new things, including continuation-based flow. Now 
his behaviour to grasp new things can be confusing (he knows this). In 
order to understand new things, he compares them to what he knows, and 
follows quickly a number of "thought-tracks" trying to find all that is 
good and bad in the new thing he wants to understand, and trying to do 
the same thing with what he already knows. This leads to some cahotic 
(it's his own word) posts, where one cannot really know if he tries to 
understand or to destroy the new thing.

Unfortunately, this led him to be classified in the anti-flowscript 
people, and the pro-ReST/FSM people. Just because he tried to compare 
what he already knows with what he wants to learn. And this also led you 
to send him harsh replies when he was just crying for help to grasp the 
concepts behind flowscript.

Being in a sad mood because thrown away from the public list, he asked 
me privately some explanations, because he thought I was knowledgeable 
after having read my answer to Pier's call center use case (again no 
link, I'm offline). So yes, we started discussing privately because he 
wasn't welcomed in public discussion.

After a few exchanges, me explaining the relationship of flow and 
continuations to the approach he already knew, we came to the conclusion 
that all these were actually different views (or increased constraints) 
on the same concept. As we did not wanted to continue this in private, 
we decided to propose some little changes (the RT), and dump the results 
of our discussion on the wiki.

Now Marc's reactions, that you qualify as personal attacks, seem to me 
the result of this sad mood and the double-speech used by Chris about 
the scratchpad (see my answer to his post).

> Can we start over again (third time!) and work to find consensus on  
> these issues? 

No. As I said, I will drop it for now, and wait to have more mean and 
for more people to have itches (mine will not stop). This proposal about 
so minor changes already caused too much bad energy. If Marc and I could 
have envisioned this, we would have shut our mouth. But we would have 
been frustrated not to be able to open it.

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

See above. Marc feels sad because you were harsh with him when he just 
wanted to learn.

>> 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 don't know if I want to vote on this. At least, *I* don't want to 
start it. There have been so much emotion around this that whatever the 
vote results, some people will keep anger about it. As I said, let's 
time and itches do their job.

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

I guess I didn't made myself clear. By "outside world", I wasn't 
referring to private business projects, but other *technologies* like 
Struts, BPEL4WS or whatever.

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

Yep. Hope mine is clearer too.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message