Sylvain,
I can see from your response that this discussion has become adversarial , and I regret that. I remember, after Ovidiu, you were the first person to welcome me to Cocoon, and you have always seemed to have a good and positive attitude.
You're right on both points. I've been present on Cocoon lists for a bit less than three years, and the number of times I came to this kind of speech can be counted on less than the fingers of a single hand. And I also welcomed you because I was (and am still) very supportive to Ovidiu's ideas and work, and helped him integrate the flow layer in the sitemap.
I don't like the tone of our recent messages, and I'd like to change it. Is that possible? My objections to the proposal you and Marc made were simply based on the fact that I feel like Cocoon is (finally) on the verge of realizing the vision Ovidiu introduced to it two years ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100715975517943&w=2
That vision was indeed based on continuations and programming languages as (later) reflected in the names of the sitemap elements. Maybe it's a small point but to me it seemed unnecessary to change that right now.
This may be subjective, but for me, the vision remains regardless of what programming language is used to depict the page flow. In Christian Queinnec's original work it was Scheme, now, in Cocoon, it's JavaScript. If we were to implement Brakes-based Java continuations it could be Java or Jython, etc.
However, I felt something was lost from that vision, for me anyway, with the proposed abstraction. That is why I objected to it.
Nevertheless, as you point out, other "visions" of page flow are possible, and I certainly don't want to discourage anyone from pursuing them.
As I stated, I've been very supportive to the ideas and philosophy behind the flow, and quickly grasped what continuations brought to the picture (refer to my numerous posts answering questions about it). BTW, I learned Lisp when I was 16 or 17 with a book written by the same Christian Queinnec that proposed to use continuations for webapps flow.
Now we've come to a time where the flow is no more "purely internal" to Cocoon, and has to be explained, teached and more generally advocated to the vast world of people that are not Cocoon developpers nor hard-core programmers. And this is where I realized that many people are not yet ready for that and don't want to abandon what they use everyday, even if these are ugly goto's.
Because of that, Cocoon must be able to host page flow technologies other than continuations, perhaps until continuations become mainstream and widely used. Once again, continuation-based flow must be the officially endorsed implementation, but we must allow other implementations, even if we don't officially promote their usage. And if code location is important for that, these alternate implementations can be hosted elsewhere.
I'm happy also to see you're not firmly attached to JS. Although a scripting languages take more and more importance, many people also are reluctant to using something else than Java server-side. And this is why I firmly believe in a pure Java solution as Brakes can help us to build.
This is what led me to consider that JS+continuations, although mind-blowingly powerful, could not be imposed to all because it _is_ mind-blowingly powerful and not everybody is able to understand nor master its power yet. Minds will have to evolve for that.
Now I'd like to apologize if I misinterpreted your posts. I don't like personal frictions, as they're often based on some initial misunderstanding that keeps unresolved. I love this community which I consider as my home (but not my property) and don't want long-term bad feelings that can only do harm.
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
