cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Bruchez <e...@bruchez.org>
Subject Re: [CocoonInAction] 2 new articles
Date Sun, 17 Apr 2005 18:27:27 GMT
Sylvain Wallez wrote:

 >> Look at this page :
 >> http://www.orbeon.com/community/cocoon
 >> I don't know exactly if all this information is verified, but I think
 >> this type of comparison is a good point.
 >
 > We looked at it, and some points in this comparison are clearly wrong.

Sorry to interfere on Cocoon's dev list: I admit that I keep an eye on
it, especially when I see the name of my company and product :-) Be
assured that this email is written in all friendliness.  As Sylvain
mentioned, we met once, and I have met Bertrand (who like me operates
out of Switzerland) a couple of times now, and I have no reason to
believe that these two Cocoon-ers in particular are anything but great
people.

I would like to say that after this Orbeon PresentationServer (OPS) /
Cocoon comparison was first mentioned in cocoon-dev, when it was still
called the OXF platform, we got some feedback and promptly updated the
page. But it's not the first time since then that I read on cocoon-dev
that the comparison is incorrect / unfair / evil / heretic (because it
dares pretend that something out there may do some things better than
Cocoon!) - ok, I am making that up, but that's a little how it looks
to me. But we have yet to get a single feedback email telling us
exactly what's wrong with the current version.

I don't believe the comparison can be all wrong, or even all unfair,
even if there is certainly subjectivity in it, and even if we mainly
mention OPS's strengths rather than weaknesses. Just looking at the
main points we make:

o Our belief that XForms is an excellent choice is subjective, but
   there are some good arguments for XForms, server-side and
   client-side (hey, I am giving a talk about server-side XForms at
   XTech 2005), and we hope to convince people who think the same to
   use OPS. That's not denying Sylvain's excellent work on Cocoon
   Forms.

o We do strongly believe that the XML pipeline language in OPS beats
   the ... out of Cocoon pipelines ;-) By the way we now have a draft
   spec hosted at W3C:

   http://www.w3.org/Submission/2005/SUBM-xpl-20050411/

   We encourage any person dealing with XML (including Cocoon-ers) to
   have a look at it and to submit feedback on the ops-xpl mailing-list
   (which intends to discuss XPL 100% independently from OPS):

   http://forge.objectweb.org/mail/?group_id=168

o The separation of concerns issues have been discussed on cocoon-dev
   by fervent Cocoon-ers: the sitemap for example is quite a mixup of
   different things. Of course there is some separation of concern in
   Cocoon, there is no denying this, but for example OPS separates
   clearly the concept of "sitemap + page flow" (which we call "page
   flow" because it declares pages as well as the relationship between
   them) from pipelines; the OPS page flow clearly separates page views
   and page models, and encourages developers to follow this
   model. Hence the claim that OPS has greater separation of concerns.

o The OPS platform consistency has been defended on this very
   mailing-list by Cocoon-ers who have read the OPS documentation
   and/or tried the platform. On the other side I have read here from
   how Cocoon can be a complex web of different things that are
   difficult to sort out. I don't think that it is unfair for us to
   mention that we believe that more consistency is a benefit, and to
   claim that OPS has more of it.

o Declarative Page Flow. Ok this is arguable, as some people will love
   Cocoon's JavaScript-based (and more programmatic) approach, which is
   very flexible and a very interesting model. So far we believe that
   the more declarative you get, the better.

o Commitment to XML standards. See the XForms section. And also, we
   love having XML Schema and Relax NG tightly integrated with
   pipelines. We also believe that it is important to integrate XSLT
   2.0 and XPath 2.0 early. So we encourage users, through
   documentation, tutorial and examples, to use those technologies, and
   that's what I call being committed to XML standards. And we also
   believe that this has benefits.

o Minimal need for Java code. Most of the applications you build with
   OPS don't require any Java code. From what I've heard, Cocoon's
   approach is still a little different. I guess sitemap actions are
   pretty obsolete by now, but they are there and people keep talking
   about them; same for XSP. I write Java code on a daily basis, but I
   do think that reducing the need for Java code in the presentation
   layer is a very sound approach, and my definite impression is that
   Cocoon doesn't go as far as OPS in this respect.

Follows on the comparison page a matrix comparing individual
features. Maybe that's where there are issues? Then please, let us
know (or let me know directly) where the problems are. It's going to
be more productive than labeling the comparison matrix as unfair.

Anyway, the goal of this long list was to make it a little clearer
where the comparison matrix and claims in favor of OPS come from. I
hope I have succeeded.

 > BTW, I met one of Orbeon's founders and he explained me they started OPS
 > because they were frustrated by Cocoon 1. Now Cocoon people also were
 > frustrated, and this led to Cocoon 2.

Actually, we were frustrated with Cocoon 2. That was back in 2002, and
our company's web site was made with Cocoon 2 at the time. I also had
a couple of personal web sites running on Cocoon 2. Just setting the
record straight ;-)

-Erik

Mime
View raw message