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 all.
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> -- Steven Noels http://outerthought.org/ Outerthought - Open Source Java & XML An Orixo Member Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
