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 to
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 what
kind of problems. I suspect that you have lots of ideas how this thing should
evolve and what kind
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 would
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 like
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 which
was a perfect chance to read some books and papers. Let's start with a quote
from a master thesis
"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 by
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
implemented."
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 that
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, etc.
Anyway, can you think of almost complete implementation of XSLT 1.0 spec. in
2000 lines of Java? I
cannot.
Even more surprising, I can moderately easily read that code even if I'm not
fluent in Haskell. I
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, there
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 and
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 (at
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 on
providing functional implementation of sitemap (that would be inspired by some
characteristics of
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 I'll
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...
[1] http://www.fh-wedel.de/~si/HXmlToolbox/xslt/thesis.pdf
[2] http://www.scala-lang.org/
[3] http://book.realworldhaskell.org/read/types-and-functions.html#id577931
[4] http://en.wikipedia.org/wiki/Pure_function
--
Best regards,
Grzegorz Kossakowski
