cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Re: Fed up with build discussions: proposed deal
Date Wed, 02 Jun 2004 13:38:08 GMT
On 27 May 2004, at 19:01, Stefano Mazzocchi wrote:

> Steven Noels wrote:
>> For these and other issues, we are unfortunately being forced now to 
>> do our own thing in order to provide our customer with something we 
>> are able to support and defend both technically and legally. I'll 
>> miss the continuations concept though. :-/
> Can you tell us more about this?

(I've been away for a couple of days and getting my answer right took 
me some time.)

Obviously, I'm talking about Daisy development here, which is slowly 
getting ready for an internal summer release. Internal in the sense of 
the original funding customer, somebody who we have been working with 
for the past three years, and who we are, amongst many other things, 
helping to migrate their entire IT department (30-ish developers, 
20-ish business applications) from a client-server Cobol legacy to 
Java, webapps and distributed components.

Learning people to make the quantum leap from Cobol to OO and Java 
isn't a small feat already, and we learned over the course of these 
years that we should be careful when introducing new stuff to them 
(like transitioning from Ant to Maven, Struts to Cocoon, or DOM/SAX to 
XMLBeans, shifting from JBoss/EJB to lightweight component containers, 
etc etc). When we build stuff that they are eventually going to use, we 
need to be careful to be able to support them, and to educate them 
about the technologies we inflict upon them. When we say "support", 
that means we are able to solve their problems whatever it takes. So we 
tend to be conservative, and stick to things we understand ourselves 
pretty well, even on the atomic level. We maybe only using 20% of 
Cocoon this way, the part we know well and know how and why it works. 
That doesn't mean we think the other 80% doesn't work, it's just that 
we have no real-life experience with it. Our brains are only moderately 
sized and can't possibly know/understand everything.

We have been doing a non-trivial amount of FlowScript coding over the 
past month. The Cocoon-side of Daisy uses (Java) Daisy repository 
client classes, communicating XML across HTTP (using Jakarta 
httpclient), going back-and-forth between CForms forms and the back-end 
document repository through a custom CForms binding. FlowScript was 
used to call our Java client and direct page flow. We happened to be 
far less productive than what we are used to, because we had to fall 
back to a trial-and-error development model, something we don't like at 

After one month, we sat down with the customer and talked through the 
issue. The customer didn't like the fact he was obliged to learn 
JavaScript, a seemingly similar yet very different programming 
language, in order to work on/with our code. He also felt that the 
transition to Java was already "enough" for his organization, and that 
JavaScript shouldn't be added to the mix. Also, even after we made our 
mind up and switched to FlowScript, he had kept on playing with Apples 
and felt this being *his* way to move forward. And we felt relieved and 
more confident after expressing the fact that we had jumped onto a 
lesser-known vehicle than what we could afford, and that we would now 
switch back to an Apples/Action combo. Hopefully we will be able (i.e. 
have time) to work further on Apples and make it better than the state 
at where we left it, since we like the SoC introduced by FlowScript and 
the map:call mechanism - so that we can stick to Apples-only rather 
than the current Apples/Actions combo.

All this with lots of mixed feelings and even some word fighting 
amongst the three of us, but in the end, we believe we are doing Daisy 
a favour by not adopting FlowScript as-is, and ATM we don't have the 
time, energy and belief to fix things anyways. Besides, I'm personally 
very worried about the "situation" of the Rhino+cont fork. And from a 
language and implementation perspective, I'm not really sure whether 
Java continuations or continuations support in Groovy is what we are 
looking after, besides the fact that it is still very early days for 
the former, and blue-sky-thinking-time for the latter.

Hope this clarifies things a bit.

Steven Noels                  
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at  
stevenn at                stevenn at

View raw message