cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Where is Cocoon 3 going to?
Date Tue, 25 Nov 2008 22:15:55 GMT
Reinhard Pötz pisze:
> Grzegorz Kossakowski wrote:
>> Cocoon 3.0 started by Reinhard looked promising to me but now I
>> realize that the main idea of its existence is to more or less
>> rewrite C2.2 and add some RESTful features.
> Yes, that's explained by the first paragraph of the Cocoon 3 website.

Ahhh right, I've looked at source code of C3 but forgot about the website. Apparently, I have
check recent developments of C3.

> You probably have missed it but with Simone we actually have one very
> active committer and I know that many other people are fond of the
> Cocoon 3 pipeline module.

Yes, sort of.

> Currently the main problem is that most developers don't know that there
> is such a simple thing as the Cocoon 3 pipeline library. I've already
> started to provide documentation but haven't got very far yet. But be
> assured that it has a very high priority on my opensource todo list.

Good to hear that. Some advertising company on e.g. Pipeline library that would show us it's
potential would be useful but it might be that I ask for way too much. ;-)

>> Has anyone here thoughts on this topic or it's only me who has a
>> problem?
> When I started Cocoon 3 my main goal was to solve two problems: 1)
> provide a plain and simple pipeline API that is easily usable from
> within any Java environment 2) make Cocoon a simple platform for RESTful
> services.
> This made *me* excited about it and solves *my* problems. I haven't done
> any market research about what would have excited others.

It would be very nice if you could provide some more details how it solved your problems and
kind of problems. I suspect that you have lots of ideas how this thing should evolve and what
of new opportunities it brings to us.

I would really like to help you with building up the community but before I can start doing
that I
need a solid background, a vision so I can guide others. That's why I'm asking for all of
that all
of the time.

> Anyway, I don't think that it makes much sense to talk about what an
> anonymous mass of people might want. So Grzegorz and all others reading
> this, what would make *you* excited about Cocoon 3 so that *you* would
> be willing to contribute?

Actually, I find myself at the crossroads now. I haven't done anything really pleasant that
make me happy with C2.2. The COCOON-2216 issues almost killed my whole motivation when it
comes to
C2.2. I feel like the time I can hack C2.2's core is over for me. Until someone helps me with
this I
will probably stay away of C2.2 completely because this issue blocks most of my plans when
it comes
to C2.2.

That's a reason for me to look for something new.

SSF should get some attention so SAX forwarding is implement and some caching bugs are fixed.
Anyway, I would like to leave this task for someone else as it's a bad situation that it looks
only me and you have an idea what's going on there. I want someone else to become involved.

So the only thing left is C3. What would make me excited? The best thing would be to rewrite
C3 in
some pure functional language like Haskell. ;-)

Ok, that's a joke but an introduction to something more serious. I've been off-line a while
was a perfect chance to read some books and papers. Let's start with a quote from a master
"Implementing an XSLT processor for the Haskell XML Toolbox" by Tim Walkenhorst[1]:

"The processor is written in a purely in Haskell 98 and does not make use of any advanced
libraries. [...] It might be possible to make the implementation even shorter and more concise
using this features; however, the basic implementation should enable interested volunteers
to gain familiarity with the code rather quickly. The entire implementation has about 1800
lines of code and is thereby 192 times smaller than the XALAN Java implementation which
has about 347000 lines of code.[...]
Of course, we could not implement the full functionality of
such a huge tool within one master thesis; however, it should be possible to perform the
most common kinds of stylesheet transformations within the subset of XSLT we

You read it correctly. The XSLT processor implemented with 1800 lines of Haskell vs 347000
lines of
Java. I've checked features and parts of specification that are not implemented and I found
they don't form a big portion of the whole specification and seemed to be rather trivial implement.
Of course, this processor does not additional features of Xalan like support for debugging,

Anyway, can you think of almost complete implementation of XSLT 1.0 spec. in 2000 lines of
Java? I

Even more surprising, I can moderately easily read that code even if I'm not fluent in Haskell.
guess I'm not the only one realizing that a reason for such a phenomenon must be something
more than
just a fancy syntax.

                                 --------------  o0o  --------------

Of course, proposing to reimplement something like Cocoon would be just a joke because there
is only
a little industry support for Haskell and Apache is definitively industry-oriented. However,
is a compromise solution called Scala[2]. The main advantage (and disadvantage at the same
time) of
Scala that it's been designed from scratch to play well with Java but at the same time incorporate
functional programing features and ideas.

It's looks to me that in C3 the idea of using scripting language for flow/controller has been
abandoned. I've never been a great supporter of scripting languages with weak typing like
Javascript. At the same time, I can understand those people that see scripting languages sexy.
Obviously, there are some constructs that are awkward and verbose (thus overly complicated)
in Java
and much simpler counterpart in some scripting language. On the other hand, lack of refactoring
need for extensive unit-testing for every little-stupid-thing is a major problem with scripting
languages. A nice paragraph[3] on that can be found in "Real World Haskell" that has just
hit the
shelves and additionally is available for free online.

Anyway, there is a third option provided by functional languages which *are* strongly typed
least those that I'm aware of) but at the same time provide flexibility found in scripting
languages. Therefore I would like to work on integrating Scala into Cocoon.

This idea is rather fresh and I'm only starting with Scala but idea would be to implement
two parts
of Cocoon in Scala:
1. Sitemap (or something corresponding)
2. Controllers

I guess this e-mail is already long enough to cut it here. If you are interested in my ideas
providing functional implementation of sitemap (that would be inspired by some characteristics
bash) I could write a little bit more on it with some details.

If there is no interest in such subject and I do not find any other interesting thing to do
probably start a fork of C3 at GitHub so it won't interfere with your work here.

Having pipelines as capable higher-order functions seems to be a neat idea...


Best regards,
Grzegorz Kossakowski

View raw message