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