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 Thu, 17 Jul 2003 09:12:50 GMT
Christopher Oliver wrote:

> 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 

> 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:
> 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message