Stefano Mazzocchi wrote:
<snip/>
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).
<snip/>
[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 ;-)
<snip/>
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 ;-)
<snip/>
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 scratch.
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 (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).
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
-- 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
