You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@apache.org> on 2008/11/25 15:24:37 UTC
Where is Cocoon 3 going to?
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.
> It's not my intention to criticize anyone but I really think it's not
> enough to make others excited and willing to contribute. At least it
> looks that way...
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.
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.
> 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.
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?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: Where is Cocoon 3 going to?
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Simone Gianni pisze:
> Hi Grzergorz,
> I've been reading of this thing of "write the same stuff using just a
> few lines, not like in java" all over in the last two years, and I
> tested it out using a large number of these languages, from Python to
> Ruby to Scala, and I can assure you that it is mostly FALSE.
I don't know Python enough to formulate any strong claims but it looks to me that Python, Ruby and
Scala does not have feature "lazy evaluation". I consider this feature as one the most important if
IMHO if you try a language without it then you are playing with not a pure (fully) functional
languages. This leads to different conclusions and experience, obviously.
Actually, the whole claim about the number of lines of code was more to spur a discussion than a
real argument. I'm sure that everyone would stop reading my mail as soon as I would start talking
about how mathematical models can be very easily expressed in functional languages or how we can
easily _reason_ on functional statements. This all results in better code but I didn't wanted to
write an e-mail full of details that nobody would read.
> On one side, surely Java IS a verbose language, and surely there can be
> more concise ones, but the entire idea of line counting is an error. I
> can pretty well write Xalan in a single line of Java code, it's just a
> matter of executing s/\n// on the whole source code :) :)
Have a look at the code of that processor, it's readable, really.
> In fact :
> - Many tools out there (CLOC just to mention one) consider also the
> closing bracket a line of code, while obviously it is not.
> - Using chaining (like A.b().c().d().e().f()) will reduce 5 "lines of
> code" to one, but in reality you are always writing 5 calls .. same
> amount of headache and possible bugs, or even more cause your code is
> less readable.
Of course, you can play tricks or you can have sexy syntax so you get less lines of code. However,
can you think of a syntax that is readable and compresses your code by factor of 100?
What I wanted to say using argument of LoC is that it looks like functional languages lets you to
express the essential idea leaving out the details. Functional languages operate on a different
level of abstraction. This is something different than having 5 methods calls in one line or
declaring or not getters and setters for a object's field for example.
> Also considering a better metric, like the number of join points or
> branches or whatever else, there are a number of reasons why these
> claims are at least exaggerated :
> - Many of these languages have huge libraries, with hundreds of methods
> that accomplish most tasks that would require you to write lines of code
> in java. This is not a bad thing in itself, but to make an appropriate
> count of lines of code you should put all these stuff in a separate
> library (commons is there for this reason), and see how many "lines of
> code" are present in your CORE code.
If there is a core library that can be useful for every application and reduces size of your code so
much then it only proves the power of expressiveness of the language in which such a library has
been implemented.
> - Most of these libraries are not customizable in any way, they do work
> perfectly 90% of times which is good, but you will end up having to
> re-implement part of these. Java went the opposite way : the bare
> minimum on the common library, no facades except where really really
> useful, which will require a lot of code from the programmer. None of
> the two is the perfect way, both have drawbacks.
I have lesser practical experience with libraries from functional languages but up to know I have
seen only extremely generic libraries in Haskell. They are so generic that you cannot compare then
to Java mainly because they are just higher-order functions.
> - Many of these libraries are tiny in number of lines because they are
> also tiny in functionalities. For example :
> ... They don't implement what they claim to completely, or implement an
> early version of it, partially and in a buggy way.
> ... Have not gone thru the pain of adding all the features users will
> ask you to add, which can make a simple one-man-show library grow up to
> thousands of hundreds of lines in a few years.
> ... Have not gone thru any test or bugfixing, and bugfixing WILL
> ENORMOUSLY increase the "size" of code (and also make it a mess).
I wholeheartedly disagree with the last statement. I've written lots of code in Java which has been
buggy and you can easily point your finger at the very specific line of code where the particular
bug has been made and this way prove that it was entirely my fault.
I don't want to dismiss that simple fact but I do bring into question if it's not a tool (Java) that
makes it too easy for me to make simple bugs. These days it's rather common saying that if you write
a big application in Java you have to cover it with both test-cases and integration tests in order
to avoid obscure bugs and long debugging sessions. I was the one saying the same, actually.
However, I started to realize that this approach seems to be broken to some extent. In test-case you
execute actions that are meant to check whether your code follows the behaviour you intended to
describe in original code.
What about a language that is precise and abstract enough that lets you describe what it should
really do (read what you really mean) instead of what kind of actions it should perform? What about
a language that is immune to most of simple bugs in code we make because it simply does not operate
at level were this bugs are made?
I happen to attend lectures on mathematical logic and subject called "Languages, Automata and
Computations" which give me lots of insights into the subject we are discussing. Even if my
understanding of the subject is at introductory level I've got more and more reasons to think that
languages can be powerful enough to express your needs so precisely that unit testing and similar
surrogates are not needed in most situations. This is only heuristic claim based on some theorems
I've learned, though.
> ... Usually does not have all the fluff around the basic core, like
> utilities, error messages, handling of special cases or exceptions, and
> so on ... that will also make your code multiply in size.
Actually the XSLT processor follows specification when it comes to error reporting. Anyway, you are
right that in general all boring details make our code bigger but still not 100 times bigger or so...
> Obviously, there are languages which are easier than Java, more concise,
> more performant and all the rest, functional approach is easier than
> passing Runnables, there are no doubt about the fact that our industry
> is young and there is huge space for new technologies, and probably
> Cocoon would greatly benefit from some of them.
Yep, that's my whole idea. This community used to be very innovate (maybe not so good at marketing
but we all know that already) and I would like to put at least some parts of Cocoon at bleeding edge
again.
Neither I'm a salesman trying to sell you a hype nor I feel like a chosen one to change a world of
programming. I simply believe that Cocoon community would benefit from a little bit of functional
programming.
> But take these revolutionary claims for what they are : propaganda, not
> necessarily real facts, or at least not THAT MUCH as they try to
> demonstrate.
Actually, as I've already said I've cited such claims to spur a discussion and I have more deep
insights into whole subject. Anyway, we both understand that nobody here wants to listen to a _very_
abstract talk on language theory that would support my current interests and the whole excitement
about them.
Moreover, I take into account that I might be simply wrong and there is no added value coming with
functional languages. However, we'll never know until we experiment with some real world
application. Cocoon's reimplementation looks like a perfect chance and here I simply ask if others
are interested in experimenting.
PS. Thanks for your comments Simone. It's been a long time since we talked last time!
--
Best regards,
Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
Posted by Luca Morandini <lm...@ieee.org>.
Simone Gianni wrote:
>
> On one side, surely Java IS a verbose language, and surely there can be
> more concise ones,
You got to try APL to fully understand what "conciseness" is, not to
mention Whitespace... but, ultimately, programs are read by humans
(literate programming, anyone ?).
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: Where is Cocoon 3 going to?
Posted by Simone Gianni <si...@apache.org>.
Hi Grzergorz,
I've been reading of this thing of "write the same stuff using just a
few lines, not like in java" all over in the last two years, and I
tested it out using a large number of these languages, from Python to
Ruby to Scala, and I can assure you that it is mostly FALSE.
On one side, surely Java IS a verbose language, and surely there can be
more concise ones, but the entire idea of line counting is an error. I
can pretty well write Xalan in a single line of Java code, it's just a
matter of executing s/\n// on the whole source code :) :)
In fact :
- Many tools out there (CLOC just to mention one) consider also the
closing bracket a line of code, while obviously it is not.
- Using chaining (like A.b().c().d().e().f()) will reduce 5 "lines of
code" to one, but in reality you are always writing 5 calls .. same
amount of headache and possible bugs, or even more cause your code is
less readable.
Also considering a better metric, like the number of join points or
branches or whatever else, there are a number of reasons why these
claims are at least exaggerated :
- Many of these languages have huge libraries, with hundreds of methods
that accomplish most tasks that would require you to write lines of code
in java. This is not a bad thing in itself, but to make an appropriate
count of lines of code you should put all these stuff in a separate
library (commons is there for this reason), and see how many "lines of
code" are present in your CORE code.
- Most of these libraries are not customizable in any way, they do work
perfectly 90% of times which is good, but you will end up having to
re-implement part of these. Java went the opposite way : the bare
minimum on the common library, no facades except where really really
useful, which will require a lot of code from the programmer. None of
the two is the perfect way, both have drawbacks.
- Many of these libraries are tiny in number of lines because they are
also tiny in functionalities. For example :
... They don't implement what they claim to completely, or implement an
early version of it, partially and in a buggy way.
... Have not gone thru the pain of adding all the features users will
ask you to add, which can make a simple one-man-show library grow up to
thousands of hundreds of lines in a few years.
... Have not gone thru any test or bugfixing, and bugfixing WILL
ENORMOUSLY increase the "size" of code (and also make it a mess).
... Usually does not have all the fluff around the basic core, like
utilities, error messages, handling of special cases or exceptions, and
so on ... that will also make your code multiply in size.
Obviously, there are languages which are easier than Java, more concise,
more performant and all the rest, functional approach is easier than
passing Runnables, there are no doubt about the fact that our industry
is young and there is huge space for new technologies, and probably
Cocoon would greatly benefit from some of them.
But take these revolutionary claims for what they are : propaganda, not
necessarily real facts, or at least not THAT MUCH as they try to
demonstrate.
Just my 2 cents.
Simone
Grzegorz Kossakowski wrote:
> 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
>
>
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/
Re: Where is Cocoon 3 going to?
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
El mié, 26-11-2008 a las 14:19 +0100, Luca Morandini escribió:
> Sylvain Wallez wrote:
> >
> > I know this mail brings more questions than answers, and Cocoon has to
> > reinvent itself, both from a technical and a community point of view.
> > Are we ready for this reinvention? Can a consensus emerge on what it
> > should be? The answer is ours.
>
> To put it succinctly: Cocoon has, mostly, failed to be a popular
> one-stop framework for web application development, and this while the
> focus on XML faded, leaving Cocoon a bit passè.
>
> As a matter of fact, I am now developing using the Hibernate/Cocoon
> 2.2/DoJo stack in RESTful-style applications, and still found the
> sitemap a breeze to use for managing the URI- and HTTP methods- space,
> but I renounced to continuations and Cocoon Forms (not RESTful enough).
>
> In the end, I think Cocoon is great for views (XML processing, i18n,
> URI-space management), so-and-so for controllers (which should be on the
> client anyway), irrelevant for models.
>
> Hmm... given the above, I'd rather concentrate on views and sitemap,
> like: standardizing the expression language between sitemap and JX
> templates, better support to JSON, etc.
>
Actually more or less the same here. I like the sitemap concept since it
allows my team to create "connectors" and in our portal we can just use
the matches from the connectors. It is an abstraction layer since we
have x different data sources (from db to the different flavors of cms),
further this data sources are moving targets so we need to have this
abstraction to not have to change our presentation layer all the time.
Never had been a big fan of the flow/forms stuff since IMO there are
other more qualified tools for this kind of development (like e.g.
Sylvain pointed out) and if I used flow it was java based.
Like Luca said
> Cocoon is great for views (XML processing, i18n,
> URI-space management), so-and-so for controllers (which should be on
the
> client anyway), irrelevant for models.
where I need to say more front-end controller then other stuff.
Regarding the models cocoon should provide a clean easy to use approach
to pass models to the different components but not much more.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
Open Source Java <consulting, training and solutions>
Sociedad Andaluza para el Desarrollo de la Sociedad
de la Información, S.A.U. (SADESI)
Re: Where is Cocoon 3 going to?
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Luca Morandini pisze:
>
> Hmm... given the above, I'd rather concentrate on views and sitemap,
> like: standardizing the expression language between sitemap and JX
> templates, better support to JSON, etc.
Standarizing expression is a task more for 2.3. Actually most of the code is already in place. There
are only a few open bugs that are blocking this to happen.
It's a pity I'm not able to tackle them...
>
>> Thanks for reading so far.
>
> Don't mention, it was a pleasure.
>
> Regards,
>
> P.S.
> If people keep insisting on functional languages, I will launch my bid
> for a total conversion of Cocoon to the one and only OO language:
> Smalltalk !
> ;)
That would be dangerous. ;-)
--
Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
Posted by Luca Morandini <lm...@ieee.org>.
Sylvain Wallez wrote:
>
> I know this mail brings more questions than answers, and Cocoon has to
> reinvent itself, both from a technical and a community point of view.
> Are we ready for this reinvention? Can a consensus emerge on what it
> should be? The answer is ours.
To put it succinctly: Cocoon has, mostly, failed to be a popular
one-stop framework for web application development, and this while the
focus on XML faded, leaving Cocoon a bit passè.
As a matter of fact, I am now developing using the Hibernate/Cocoon
2.2/DoJo stack in RESTful-style applications, and still found the
sitemap a breeze to use for managing the URI- and HTTP methods- space,
but I renounced to continuations and Cocoon Forms (not RESTful enough).
In the end, I think Cocoon is great for views (XML processing, i18n,
URI-space management), so-and-so for controllers (which should be on the
client anyway), irrelevant for models.
Hmm... given the above, I'd rather concentrate on views and sitemap,
like: standardizing the expression language between sitemap and JX
templates, better support to JSON, etc.
Just my 0.2€.
> Thanks for reading so far.
Don't mention, it was a pleasure.
Regards,
P.S.
If people keep insisting on functional languages, I will launch my bid
for a total conversion of Cocoon to the one and only OO language:
Smalltalk !
;)
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: Where is Cocoon 3 going to?
Posted by David Crossley <cr...@apache.org>.
Simone Tripodi wrote:
> Hi everybody,
> I'm the younger person - in therms of cocoon's experience - who
> recently joined Reinhard and Steven in their enthusiasm about Cocoon3.
>
> Please let me spend my 0.2??? too, feel free moving this email in the
> spam or trash box :)
Thanks for your comments. Very important.
> Just a prelude: I've never experienced using oldest Cocoon's release,
> but months ago, while I was working on an important OpenID provider
> (for the biggest Italian Telecommunication company), I had the need to
> generate , manipulate, validate, transform and serialize large XML
> data set in various format.
> So I felt the need to use a solid framework able to help me in a quick
> and clear way... so, the miracle happened when I found "accidentally"
> the Reinhard's blog.
> My first word was just a "wow!", so I wrote an email to him. I was
> totally charmed, not only about Cocoon, but above all the
> collaborative way that both Reinhard and Steven demonstrated in
> explaining me how the new Cocoon works, helping me in adopting it in
> the way to resolve my problems and involving me in the development,
> exhorting me in "bombing" the Issue Tracker :)
It would be better if we all heard those explanations
here on the dev list.
> Starting from that time, I've been evangelizing new Pipeline APIs, our
> customer are satisfied by the product we developed on top of them...
> and finally, also some friend of mine started being Cocoon3's users.
> Everybody agree that's a nice framework with - more important - an
> excellent community behind.
Please encourage your collaborators to join us.
-David
> So, in my humble opinion, Cocoon3 has sense to exist. I like it, I
> adore it, it resolved my problems and makes me enthusiastic. Reinhard
> is a great leader, and Steven an excellent guide, and this justifies -
> at least, for me - that Cocoon3's community MUST exist. I'm sure
> there's someone that, like me, one day will need joining this great
> community.
>
> Best regards, sorry for the spam :)
> Simone
Re: Where is Cocoon 3 going to?
Posted by Simone Tripodi <si...@gmail.com>.
Hi everybody,
I'm the younger person - in therms of cocoon's experience - who
recently joined Reinhard and Steven in their enthusiasm about Cocoon3.
Please let me spend my 0.2€ too, feel free moving this email in the
spam or trash box :)
Just a prelude: I've never experienced using oldest Cocoon's release,
but months ago, while I was working on an important OpenID provider
(for the biggest Italian Telecommunication company), I had the need to
generate , manipulate, validate, transform and serialize large XML
data set in various format.
So I felt the need to use a solid framework able to help me in a quick
and clear way... so, the miracle happened when I found "accidentally"
the Reinhard's blog.
My first word was just a "wow!", so I wrote an email to him. I was
totally charmed, not only about Cocoon, but above all the
collaborative way that both Reinhard and Steven demonstrated in
explaining me how the new Cocoon works, helping me in adopting it in
the way to resolve my problems and involving me in the development,
exhorting me in "bombing" the Issue Tracker :)
Starting from that time, I've been evangelizing new Pipeline APIs, our
customer are satisfied by the product we developed on top of them...
and finally, also some friend of mine started being Cocoon3's users.
Everybody agree that's a nice framework with - more important - an
excellent community behind.
So, in my humble opinion, Cocoon3 has sense to exist. I like it, I
adore it, it resolved my problems and makes me enthusiastic. Reinhard
is a great leader, and Steven an excellent guide, and this justifies -
at least, for me - that Cocoon3's community MUST exist. I'm sure
there's someone that, like me, one day will need joining this great
community.
Best regards, sorry for the spam :)
Simone
Re: Where is Cocoon 3 going to?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Nov 26, 2008 at 10:31 PM, <so...@apache.org> wrote:
> ...My
> definition is:
>
> Cocoon allows easy manipulation of XML using pipes defined in XML:
> generate/aggregate - load content
> transform - modify content using XSL.
> serialize - deliver in a variety of formats...
Agree with that, although I've been (successfully and happily)
building complete applications with Cocoon in the past, I wouldn't do
that today anymore.
But if I have to process XML data or generate various formats from
XML, the above functionalities remain a good choice - ideally
embeddable in today's java environments. That's why I'm keeping an eye
on Cocoon 3, although I haven't been able to do more than that lately.
> ...Whether XML is no longer the current fad should not be relevant.
> Cocoon is an XML processing platform built on Java. Change this
> statement, and the result would no longer be Cocoon....
Agree with that as well.
-Bertrand
Re: Where is Cocoon 3 going to?
Posted by so...@apache.org.
On 11/26/08, Sylvain Wallez <sy...@apache.org> wrote:
> Looking at our website, I think we have forgotten what forms our community:
> "Apache Cocoon is a Spring-based framework (since version 2.2 of Cocoon)
> built around the concepts of separation of concerns and component-based
> development. Cocoon implements these concepts around the notion of component
> pipelines, each component on the pipeline specializing on a particular
> operation."
>
> Sylvain Wallez - http://bluxte.net
Seems the project definition does not fit the typical first use. My
definition is:
Cocoon allows easy manipulation of XML using pipes defined in XML:
generate/aggregate - load content
transform - modify content using XSL.
serialize - deliver in a variety of formats.
This allows non-programmers to be productive writing simple XML-based
applications. Everything else is for extensibility. The many blocks,
Java programming, Spring architecture, etc. allow complete control and
the addition of almost any functionality, but the primary reason to
use Cocoon is for easy manipulation of XML.
Whether XML is no longer the current fad should not be relevant.
Cocoon is an XML processing platform built on Java. Change this
statement, and the result would no longer be Cocoon. This does not
imply that any architecture improvements are unimportant, just that
the primary purpose must be honored. Some suggestions (e.g. changing
the programming language) should require creating a new project.
solprovider
Re: Where is Cocoon 3 going to?
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Sylvain Wallez pisze:
> Grzegorz Kossakowski wrote:
>> 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.
>>
>
> Interesting thoughts, especially as I am myself interested in functional
> programming, which I started with Javascript, then learned Erlang and
> looked at Scala as a very interesting way to bring those programming
> paradigms to the Java platform.
Hi Sylvain.
Thanks for your comments. Great integration of Scala with Java is one the most important reasons why
I brought Scala into this discussion.
For others reading this thread: Scala's code compiles to a binary format understood by JVM so you
can use Java code from Scala code and the opposite way.
> Now we have to think about what this community is about, and what we can
> do to make it successful again. An open source community is a delicate
> balance between interest of developers in developing the product, and
> interest of users in actually using the product. The concept of
> "interest" covers many different aspects: for developers, this includes
> a combination of hacking pleasure, pure altruism, strengthening a
> business related to the product, socializing with like-minded people,
> etc. For users, it includes being able to be efficient and productive,
> finding support from developers and other users, and being able to
> understand the product to tune it and ultimately write bugfixes and
> patches, opening the way to committership.
>
> The Cocoon community has been a bit special in this regard, since Cocoon
> allows to do quite complex stuff with a small amount of "code" (sitemap
> and XSLT are code) and without requiring strong programming skills. I
> remember someone sending a "Thank you" email, explaining how Cocoon
> allowed him to do stuff he wouldn't have been able to do without it, and
> thus start a consulting business that allowed him to work from home and
> spend more time with his family. How rewarding for us developers! Cocoon
> allows less skilled users to _do_ stuff, and skilled developers to be
> highly productive. This is why this complex product attracted brillant
> innovation but at the same time was more accessible to average people
> than less sophisticated products.
Yep, that's a great description of Cocoon strengths. The question that comes to my mind is if we
still continue to maintain these characteristics?
> Looking at our website, I think we have forgotten what forms our
> community: "Apache Cocoon is a Spring-based framework (since version 2.2
> of Cocoon) built around the concepts of separation of concerns and
> component-based development. Cocoon implements these concepts around the
> notion of component pipelines, each component on the pipeline
> specializing on a particular operation."
Ok, that looks like an answer to the above question. ;-)
> Well, Cocoon old-timers understand what it means (at least roughly in my
> case, as I never digged into blocks). Now put yourself as a newcomer,
> especially a less skilled person representing the largest part of our
> users. What the heck is this Cocoon stuff all about? What kind of
> problems does it solve? How is it different/better than other products I
> can find at Apache and elsewhere?
>
> Cocoon has been very successful by being a superb integration platform
> for everything that can be represented as XML, and there are blocks for
> every Apache-compatible library that can produce or consume XML. Even
> music, and I've seen people's jaws dropping when I showed them the Bach
> prelude being processed in XSLT. Over time blocks have accumulated, the
> framework has been abstracted and modularized to become even more
> flexible and address even more problems, but this came with a price:
> newcomers simply can't grasp what Cocoon is about.
>
> Also, Cocoon has been an incredible source of innovation, with its
> component architecture, the ReSTful sitemap, the mighty (but complex)
> portal, server-side scripting, continuations, etc. But the outside world
> has also innovated, and new frameworks/techniques have emerged, at all
> levels of the stack: Spring as a replacement for Avalon, Wicket for
> complex forms, GWT and many others for Ajax, aggregated pages and
> portals are now replaced with Ajax gadgets, etc.
>
> The newer products aren't necessarily easier to use, but are probably
> easier to grasp because they do less, or have more introductory
> material, or are more "standard" (i.e. widely accepted, be it for good
> reasons or not). There also has been simpler approaches such as Django,
> Ruby on Rails, or the numerous PHP equivalents.
>
> Coming back to the original proposal, my opinion is that writing Cocoon
> in a functional language would be a fun exercise, but nobody would use
> it because nobody in this community would understand it. Note that I say
> _this_ community, since for example the CouchDB community happily hacks
> hard-core functional Erlang.
By introduction of flowscript many people from this community (including me) has been, in fact,
gently forced to learn that language. Given the fact that flowscript is widely used it looks like it
wasn't harmful experience.
I would like to see similar route for Scala that is gently introduced and its integration is
orthogonal to mainstream implementation. The it would be community's decision if we want to develop
and support it.
Also, I'm not proposing to rewrite everything into Scala because it does not make any sense to me;
at least at this stage.
> Also we have to consider that the XML hype is fading away and that the
> times of "everything can be represented as XML" are over, for good
> reasons or not. Welcome JSON as a replacement to XML for data
> interchange, because it's much more lightweight, native in browsers, and
> more typed than XML (it has numbers, arrays, maps).
>
> Considering this, my personal opinion is that XML pipelines still have a
> value, but this value has been reduced back to the original goals of
> Cocoon: document transformation for multiple presentations. But it's no
> more good as the foundation of a whole application since other
> techniques and new approaches (esp Ajax and JSON) have made it easier.
Our XML pipeline may serialize into JSON. The point is in how we obtain, aggregate and transform the
data. For all of this I thing XML is still the best choice.
Moreover, the fading hype of XML might be caused by some other subtle fact. Usually an XML document
is represented as a rather heavy *tree* of objects. The problem is that imperative languages (like
Java) are very bad at processing trees. At least they a way worse than most of functional languages.
Processing XML document in Java is painful and boring so it's not so surprising that people look for
something easier. Of course this only adds to your arguments.
> At least this is my feeling and own experience. At $work we have a
> full-ajax portal, and a very simple URL-matching Java library that has
> most of the sitemap matching features in a dozen classes, and a
> super-lightweight XML pipeline engine to adapt HTML pages for the web or
> mobile phones. And we use Wicket for data-intensive backoffice webapps.
>
> So what does this all mean for our community? What community of users
> should we target? The historical community described above, or a new
> kind of community? What's in Cocoon to make it appealing to newcomers?
> XML pipelines, the sitemap, server-side scripting and continuations.
> Cocoon 2.2 has buried them under a huge technical and presentational
> complexity.
>From your list my personal choice would be: XML Pipelines, Sitemap.
With rich clients the need for continuations seems to be fading away. At least I've lost interest in
this subject completely.
> Cocoon 3 builds on these core values, but is already IMHO too complex by
> having more than a dozen different modules. Note that this complexity is
> more organizational than technical, but it makes it too difficult for
> people to find their way there (that was my case). Also, a complete
> rewrite is needed, but at the same time we should not forget all the
> technical expertise that has been put in Cocoon over the years (e.g.
> cache, work arounds for well-known Xalan quirks, etc) and completely
> reinvent the wheel. Difficult exercise.
>
> I know this mail brings more questions than answers, and Cocoon has to
> reinvent itself, both from a technical and a community point of view.
> Are we ready for this reinvention? Can a consensus emerge on what it
> should be? The answer is ours.
As I've expressed I would love to see a reminiscence of Cocoon's "invention corner". We used to be
good at it, why not to continue this tradition?
> Thanks for reading so far.
Thanks for answering.
--
Best regards,
Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
Posted by Sylvain Wallez <sy...@apache.org>.
Grzegorz Kossakowski wrote:
> 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.
>
Interesting thoughts, especially as I am myself interested in functional
programming, which I started with Javascript, then learned Erlang and
looked at Scala as a very interesting way to bring those programming
paradigms to the Java platform.
Now we have to think about what this community is about, and what we can
do to make it successful again. An open source community is a delicate
balance between interest of developers in developing the product, and
interest of users in actually using the product. The concept of
"interest" covers many different aspects: for developers, this includes
a combination of hacking pleasure, pure altruism, strengthening a
business related to the product, socializing with like-minded people,
etc. For users, it includes being able to be efficient and productive,
finding support from developers and other users, and being able to
understand the product to tune it and ultimately write bugfixes and
patches, opening the way to committership.
The Cocoon community has been a bit special in this regard, since Cocoon
allows to do quite complex stuff with a small amount of "code" (sitemap
and XSLT are code) and without requiring strong programming skills. I
remember someone sending a "Thank you" email, explaining how Cocoon
allowed him to do stuff he wouldn't have been able to do without it, and
thus start a consulting business that allowed him to work from home and
spend more time with his family. How rewarding for us developers! Cocoon
allows less skilled users to _do_ stuff, and skilled developers to be
highly productive. This is why this complex product attracted brillant
innovation but at the same time was more accessible to average people
than less sophisticated products.
Looking at our website, I think we have forgotten what forms our
community: "Apache Cocoon is a Spring-based framework (since version 2.2
of Cocoon) built around the concepts of separation of concerns and
component-based development. Cocoon implements these concepts around the
notion of component pipelines, each component on the pipeline
specializing on a particular operation."
Well, Cocoon old-timers understand what it means (at least roughly in my
case, as I never digged into blocks). Now put yourself as a newcomer,
especially a less skilled person representing the largest part of our
users. What the heck is this Cocoon stuff all about? What kind of
problems does it solve? How is it different/better than other products I
can find at Apache and elsewhere?
Cocoon has been very successful by being a superb integration platform
for everything that can be represented as XML, and there are blocks for
every Apache-compatible library that can produce or consume XML. Even
music, and I've seen people's jaws dropping when I showed them the Bach
prelude being processed in XSLT. Over time blocks have accumulated, the
framework has been abstracted and modularized to become even more
flexible and address even more problems, but this came with a price:
newcomers simply can't grasp what Cocoon is about.
Also, Cocoon has been an incredible source of innovation, with its
component architecture, the ReSTful sitemap, the mighty (but complex)
portal, server-side scripting, continuations, etc. But the outside world
has also innovated, and new frameworks/techniques have emerged, at all
levels of the stack: Spring as a replacement for Avalon, Wicket for
complex forms, GWT and many others for Ajax, aggregated pages and
portals are now replaced with Ajax gadgets, etc.
The newer products aren't necessarily easier to use, but are probably
easier to grasp because they do less, or have more introductory
material, or are more "standard" (i.e. widely accepted, be it for good
reasons or not). There also has been simpler approaches such as Django,
Ruby on Rails, or the numerous PHP equivalents.
Coming back to the original proposal, my opinion is that writing Cocoon
in a functional language would be a fun exercise, but nobody would use
it because nobody in this community would understand it. Note that I say
_this_ community, since for example the CouchDB community happily hacks
hard-core functional Erlang.
Also we have to consider that the XML hype is fading away and that the
times of "everything can be represented as XML" are over, for good
reasons or not. Welcome JSON as a replacement to XML for data
interchange, because it's much more lightweight, native in browsers, and
more typed than XML (it has numbers, arrays, maps).
Considering this, my personal opinion is that XML pipelines still have a
value, but this value has been reduced back to the original goals of
Cocoon: document transformation for multiple presentations. But it's no
more good as the foundation of a whole application since other
techniques and new approaches (esp Ajax and JSON) have made it easier.
At least this is my feeling and own experience. At $work we have a
full-ajax portal, and a very simple URL-matching Java library that has
most of the sitemap matching features in a dozen classes, and a
super-lightweight XML pipeline engine to adapt HTML pages for the web or
mobile phones. And we use Wicket for data-intensive backoffice webapps.
So what does this all mean for our community? What community of users
should we target? The historical community described above, or a new
kind of community? What's in Cocoon to make it appealing to newcomers?
XML pipelines, the sitemap, server-side scripting and continuations.
Cocoon 2.2 has buried them under a huge technical and presentational
complexity.
Cocoon 3 builds on these core values, but is already IMHO too complex by
having more than a dozen different modules. Note that this complexity is
more organizational than technical, but it makes it too difficult for
people to find their way there (that was my case). Also, a complete
rewrite is needed, but at the same time we should not forget all the
technical expertise that has been put in Cocoon over the years (e.g.
cache, work arounds for well-known Xalan quirks, etc) and completely
reinvent the wheel. Difficult exercise.
I know this mail brings more questions than answers, and Cocoon has to
reinvent itself, both from a technical and a community point of view.
Are we ready for this reinvention? Can a consensus emerge on what it
should be? The answer is ours.
Thanks for reading so far.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Where is Cocoon 3 going to?
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Re: Where is Cocoon 3 going to?
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>> Simone Tripodi wrote:
>>> Hi All,
>>> just to notify you that Steven ad I already started working on a
>>> caching system in cocoon3 more that 3 weeks ago, maybe the jira's
>>> issue can provide you more infos.
>> Simone, is there more information available than
>> https://issues.apache.org/jira/browse/COCOON3-6? If yes, could you
>> please give us pointers or otherwise provide us with a summary
>> explaining what you both are working on?
>>
>> Many thanks in advance!
> I second this ask. Bombing us with patches that are not discussed here is what we all want to avoid.
Simone has created 9 patches so far. Although not all of them have been
applied yet, I don't think that we suffer from an overload. So Simone,
keep on bombing us ;-)
I also want to mention that all in all I'm satisfied with the
information that is added to each Jira issue. It was only the XSLT
caching issue which deserves further discussions IMO because, as Sylvain
pointed out, we should learn from the 2.x implementation and I'm sure
that some of the 'oldies' around here would be happy to share their
knowledge.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: Where is Cocoon 3 going to?
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Torsten Curdt pisze:
>> Honestly I have no opinion on an implementation of the sitemap engine in a
>> functional language.
>> Perhaps it's just me, but I fail to see the reason to do so.
>
> I didn't bother to search the archives ... and this might also been
> beer talk during GetTogethers where this came up before ...but IMO the
> point is not use necessarily a "functional language" but a language
> that is more suited for the job.
You probably have in mind thread started by Ugo Cei "[RT] A Groovy Kind of Sitemap"[1]. I'm still in
process of reading all replies.
Yep, the real point is to use something better than our current sitemap language. I have chosen
functional language (namely Scala) because it's my current field of interest and because I can see
benefits coming from using it.
To point out just a few:
1. More concise and natural syntax. What about pipeline looking like:
FileGenerator("a/template.xml") | XSLTTransformer("b/sth.xslt") | MyTransformer | HTMLSerializer
This is a plain Scala with a few things defined correctly. Scala has a nice support for creation
of DLSs, see[2]
2. Ad-hoc defintions of simple transformers.
3. Debugging support for sitemap.
4. Strong typing for sitemap.
> Using XML for the sitemap IMO turned out to be a very bad idea in
> retrospect. (Well, everything is XML - right) On the other hand
> writing a sitemap in a common language (javascript or something
> similar) will lead to terrible abuses (as you would only need a subset
> of whatever you pick). Coming up with your own DSL has become so
> simple that this would be my choice now these days.
Actually I don't believe that we can stop people making stupid things simply by designing a good
software. Definitively we should encourage people to use our software the proper way but working
hard on obstacles is more questionable.
Anyway, DSL-like syntax is possible in Scala.
> I have already seen so many people adopt the sitemap concept in other
> projects. (I wish httpd would adopt it!) But everyone came up with
> their own implementation. "I just need a little sitemap engine". Let's
> face it the component re-use in that aspect is a bit of a myth. (Poll:
> how many people re-use cocoon components in other projects as is?)
>
> Maybe it's time to learn from the Cocoon strengths and turn parts of
> it into APIs. The pipeline API is a good example. I guess this is the
> only way to revive Cocoon's future.
+1 for that.
I guess we all agree that we want to create something more than just a pipeline API and its
implementation, right?
Anyway, it's good that this work has started. Rewriting from scratch but based on our expierience
brings some new opportunities.
[1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/39351
[2] http://www.scala-lang.org/node/104 (Scala is extensible section)
--
Best regards,
Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
Posted by Torsten Curdt <tc...@apache.org>.
> Honestly I have no opinion on an implementation of the sitemap engine in a
> functional language.
> Perhaps it's just me, but I fail to see the reason to do so.
I didn't bother to search the archives ... and this might also been
beer talk during GetTogethers where this came up before ...but IMO the
point is not use necessarily a "functional language" but a language
that is more suited for the job.
Using XML for the sitemap IMO turned out to be a very bad idea in
retrospect. (Well, everything is XML - right) On the other hand
writing a sitemap in a common language (javascript or something
similar) will lead to terrible abuses (as you would only need a subset
of whatever you pick). Coming up with your own DSL has become so
simple that this would be my choice now these days.
I have already seen so many people adopt the sitemap concept in other
projects. (I wish httpd would adopt it!) But everyone came up with
their own implementation. "I just need a little sitemap engine". Let's
face it the component re-use in that aspect is a bit of a myth. (Poll:
how many people re-use cocoon components in other projects as is?)
Maybe it's time to learn from the Cocoon strengths and turn parts of
it into APIs. The pipeline API is a good example. I guess this is the
only way to revive Cocoon's future.
My 2 cents
cheers
--
Torsten
Re: Where is Cocoon 3 going to?
Posted by David Crossley <cr...@apache.org>.
Grzegorz Kossakowski wrote:
> Steven Dolg pisze:
> >>
> >> I second this ask. Bombing us with patches that are not discussed here
> >> is what we all want to avoid.
> >>
> > The number of patches from Simone hardly qualifies for being called
> > "bombing". Actually the issue mentioned has exactly one patch.
> >
> > Furthermore I doubt every single change needs to be discussed here
> > before it is made.
> > Something as straightforward as "cache the XSLT to avoid parsing it
> > every single time the pipeline is executed" is IMO one of those things
> > that should be obvious to everyone.
>
> The idea is obvious, the implementation details as we can see are not so obvious.
>
> > Especially since - as Sylvain pointed out - "this feature has been
> > available in Cocoon for ages".
>
> Yep, but if the sequence of events had been a little bit different then the patch wouldn't have to
> be rewritten. The idea is not to write detailed plan that is almost comparable with final
> implementation but simple saying "I'm going to implement this and this, using this and this. If
> someone wants to comment. Go ahead."
>
> A few sentences, right?
I too was concerned when i saw new patches to re-implement
something that Cocoon has already spent years developing.
A little bit of discussion is a good thing. It enables the rest
of the community to feel that they are still in touch with
the direction of the project.
-David
> > Not everyone is fond of reading long emails that sketch a vague picture.
> > A clear description of the problem, a suggested solution and a patch
> > that provides a working implementation is IMO sometimes preferable.
> > Everyone is able to have a look at the jira issues and the posted
> > patch(es) and comment on them just like Sylvain did.
>
> After studying recent issues on COCOON3 I have to admit that level of discussions has increased
> which makes me happy. There are several reasons why things should be discussed here.
>
> One of them is that one can grasp what has happened during his offline period.
>
> As for now let's move on more specific things. I'd like to hear your opinion on functional sitemap,
> Steven!
>
> --
> Grzegorz
Re: Where is Cocoon 3 going to?
Posted by Steven Dolg <st...@indoqa.com>.
Grzegorz Kossakowski schrieb:
> Steven Dolg pisze:
>
>>> I second this ask. Bombing us with patches that are not discussed here
>>> is what we all want to avoid.
>>>
>>>
>> The number of patches from Simone hardly qualifies for being called
>> "bombing". Actually the issue mentioned has exactly one patch.
>>
>> Furthermore I doubt every single change needs to be discussed here
>> before it is made.
>> Something as straightforward as "cache the XSLT to avoid parsing it
>> every single time the pipeline is executed" is IMO one of those things
>> that should be obvious to everyone.
>>
>
> The idea is obvious, the implementation details as we can see are not so obvious.
>
I really don't think so and I don't understand where the "as we can see"
comes from.
But maybe I'm missing something.
>
>> Especially since - as Sylvain pointed out - "this feature has been
>> available in Cocoon for ages".
>>
>
> Yep, but if the sequence of events had been a little bit different then the patch wouldn't have to
> be rewritten. The idea is not to write detailed plan that is almost comparable with final
> implementation but simple saying "I'm going to implement this and this, using this and this. If
> someone wants to comment. Go ahead."
>
> A few sentences, right?
>
>
>> Not everyone is fond of reading long emails that sketch a vague picture.
>> A clear description of the problem, a suggested solution and a patch
>> that provides a working implementation is IMO sometimes preferable.
>> Everyone is able to have a look at the jira issues and the posted
>> patch(es) and comment on them just like Sylvain did.
>>
>
> After studying recent issues on COCOON3 I have to admit that level of discussions has increased
> which makes me happy. There are several reasons why things should be discussed here.
>
> One of them is that one can grasp what has happened during his offline period.
>
> As for now let's move on more specific things. I'd like to hear your opinion on functional sitemap,
> Steven!
>
Honestly I have no opinion on an implementation of the sitemap engine in
a functional language.
Perhaps it's just me, but I fail to see the reason to do so.
I can image that this could be an interesting exercise - but for me this
alone is not sufficient.
There certainly are a lot of things that would be extremely cool to do,
but I usually don't create software without a specific need.
But maybe that's just me.
If you want to do this - just go ahead. I might even take a look at it.
But I seriously doubt that I can make any qualified statement with my
current knowledge and experience in using functional languages.
And TBH those two things are not going to change in the near future...
Re: Where is Cocoon 3 going to?
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Steven Dolg pisze:
>>
>> I second this ask. Bombing us with patches that are not discussed here
>> is what we all want to avoid.
>>
> The number of patches from Simone hardly qualifies for being called
> "bombing". Actually the issue mentioned has exactly one patch.
>
> Furthermore I doubt every single change needs to be discussed here
> before it is made.
> Something as straightforward as "cache the XSLT to avoid parsing it
> every single time the pipeline is executed" is IMO one of those things
> that should be obvious to everyone.
The idea is obvious, the implementation details as we can see are not so obvious.
> Especially since - as Sylvain pointed out - "this feature has been
> available in Cocoon for ages".
Yep, but if the sequence of events had been a little bit different then the patch wouldn't have to
be rewritten. The idea is not to write detailed plan that is almost comparable with final
implementation but simple saying "I'm going to implement this and this, using this and this. If
someone wants to comment. Go ahead."
A few sentences, right?
> Not everyone is fond of reading long emails that sketch a vague picture.
> A clear description of the problem, a suggested solution and a patch
> that provides a working implementation is IMO sometimes preferable.
> Everyone is able to have a look at the jira issues and the posted
> patch(es) and comment on them just like Sylvain did.
After studying recent issues on COCOON3 I have to admit that level of discussions has increased
which makes me happy. There are several reasons why things should be discussed here.
One of them is that one can grasp what has happened during his offline period.
As for now let's move on more specific things. I'd like to hear your opinion on functional sitemap,
Steven!
--
Grzegorz
Re: Where is Cocoon 3 going to?
Posted by Steven Dolg <st...@indoqa.com>.
Grzegorz Kossakowski schrieb:
> Reinhard Pötz pisze:
>
>> Simone Tripodi wrote:
>>
>>> Hi All,
>>> just to notify you that Steven ad I already started working on a
>>> caching system in cocoon3 more that 3 weeks ago, maybe the jira's
>>> issue can provide you more infos.
>>>
>> Simone, is there more information available than
>> https://issues.apache.org/jira/browse/COCOON3-6? If yes, could you
>> please give us pointers or otherwise provide us with a summary
>> explaining what you both are working on?
>>
>> Many thanks in advance!
>>
>>
>
> I second this ask. Bombing us with patches that are not discussed here is what we all want to avoid.
>
The number of patches from Simone hardly qualifies for being called
"bombing". Actually the issue mentioned has exactly one patch.
Furthermore I doubt every single change needs to be discussed here
before it is made.
Something as straightforward as "cache the XSLT to avoid parsing it
every single time the pipeline is executed" is IMO one of those things
that should be obvious to everyone.
Especially since - as Sylvain pointed out - "this feature has been
available in Cocoon for ages".
Not everyone is fond of reading long emails that sketch a vague picture.
A clear description of the problem, a suggested solution and a patch
that provides a working implementation is IMO sometimes preferable.
Everyone is able to have a look at the jira issues and the posted
patch(es) and comment on them just like Sylvain did.
>
>
Re: Where is Cocoon 3 going to?
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Pötz pisze:
> Simone Tripodi wrote:
>> Hi All,
>> just to notify you that Steven ad I already started working on a
>> caching system in cocoon3 more that 3 weeks ago, maybe the jira's
>> issue can provide you more infos.
>
> Simone, is there more information available than
> https://issues.apache.org/jira/browse/COCOON3-6? If yes, could you
> please give us pointers or otherwise provide us with a summary
> explaining what you both are working on?
>
> Many thanks in advance!
>
I second this ask. Bombing us with patches that are not discussed here is what we all want to avoid.
--
Best regards,
Grzegorz Kossakowski
Re: Where is Cocoon 3 going to?
Posted by Reinhard Pötz <re...@apache.org>.
Simone Tripodi wrote:
> Hi All,
> just to notify you that Steven ad I already started working on a
> caching system in cocoon3 more that 3 weeks ago, maybe the jira's
> issue can provide you more infos.
Simone, is there more information available than
https://issues.apache.org/jira/browse/COCOON3-6? If yes, could you
please give us pointers or otherwise provide us with a summary
explaining what you both are working on?
Many thanks in advance!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: Where is Cocoon 3 going to?
Posted by Simone Tripodi <si...@gmail.com>.
Hi All,
just to notify you that Steven ad I already started working on a
caching system in cocoon3 more that 3 weeks ago, maybe the jira's
issue can provide you more infos.
Best regards!!!
Simone
2008/11/25 Reinhard Pötz <re...@apache.org>:
> Peter Hunsberger wrote:
>> On Tue, Nov 25, 2008 at 8:24 AM, Reinhard Pötz <re...@apache.org> wrote:
>>> 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.
>>>
>>>> It's not my intention to criticize anyone but I really think it's not
>>>> enough to make others excited and willing to contribute. At least it
>>>> looks that way...
>>> 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.
>>> 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.
>>>
>>>> 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.
>>>
>>> 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?
>>>
>>
>> FWIW, we'll be taking a hard look at moving to Cocoon 3 vs. 2.2 as we
>> look at migrating off of 2.1. Our main requirement really is for XML
>> and XSL pipelines and we don't use most of the existing Cocoon
>> infrastructure, the big thing currently lacking is 3 that we really
>> need is caching...
>
> Could you elaborate on your caching requirements?
>
> --
> Reinhard Pötz Managing Director, {Indoqa} GmbH
> http://www.indoqa.com/en/people/reinhard.poetz/
>
> Member of the Apache Software Foundation
> Apache Cocoon Committer, PMC member reinhard@apache.org
> ________________________________________________________________________
>
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
Re: Where is Cocoon 3 going to?
Posted by Peter Hunsberger <pe...@gmail.com>.
On Tue, Nov 25, 2008 at 6:19 PM, Reinhard Pötz <re...@apache.org> wrote:
>
> IMO it would be best to discuss your needs based on what Cocoon 3
> already offers (see org.apache.cocoon.pipeline.CachingPipeline) and what
> exactly you are missing. And additionally (or alternatively if you
> prefer) you could also provide us with a concrete example. I think that
> would make many things much clearer.
>
We're not at that point yet. Although I've brought the Cocoon 3 code
up that's about all I've done with it.
As I said, our needs are complex; we'll almost certainly extend
whatever get's implemented so it would be good if things were
constructed with that in mind: reasonable interfaces, abstract parent
classes with the housekeeping methods already implemented, no final
methods, etc. Pluggable components maybe?
Which reminds me, how much thought has been given to a component based
architecture?
--
Peter Hunsberger
Re: Where is Cocoon 3 going to?
Posted by Reinhard Pötz <re...@apache.org>.
Peter Hunsberger wrote:
> On Tue, Nov 25, 2008 at 10:17 AM, Reinhard Pötz <re...@apache.org> wrote:
>> Peter Hunsberger wrote:
>>> On Tue, Nov 25, 2008 at 8:24 AM, Reinhard Pötz <re...@apache.org> wrote:
>>>> Grzegorz Kossakowski wrote:
>> Could you elaborate on your caching requirements?
>>
>
> We run an Intranet web app, (not a web site) with very complex
> dynamically assembled screens. We have fairly long pipelines, with a
> lot of aggregated components. There is almost always one component
> that cannot be cached at all (or makes little sense to cache) and the
> others have varying cache lifetimes. So currently we need to be able
> to pull cached SAX streams from the nonchanging components and run the
> results through XSLT as per standard Cocoon aggregated validity type
> checking.
>
> Any next gen version of our app will likely attempt to move this to a
> more granular approach using AJAX on the front end so it should be
> possible to eliminate most of, if not all of, the requirement for
> aggregated SAX via XSLT. However, even then, for a large chunk of our
> data we don't know exactly what can be shared until we examine
> security policies that are determined dynamically (eg, based on
> previous data requests) so we know we cannot move everything to http /
> web server type caching. Similarly, our cache invalidation policies
> are complex with hierarchies of dependencies so again you can't set
> simple http type cache expiiry policies, you've got to have something
> more like the current cocoon validity checking, where we can trigger a
> cascade of cache invalidation when some fundamental resource is
> updated.
>
> If that raises more questions than it answers I can attempt to elaborate...
IMO it would be best to discuss your needs based on what Cocoon 3
already offers (see org.apache.cocoon.pipeline.CachingPipeline) and what
exactly you are missing. And additionally (or alternatively if you
prefer) you could also provide us with a concrete example. I think that
would make many things much clearer.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: Where is Cocoon 3 going to?
Posted by Peter Hunsberger <pe...@gmail.com>.
On Tue, Nov 25, 2008 at 10:17 AM, Reinhard Pötz <re...@apache.org> wrote:
> Peter Hunsberger wrote:
>> On Tue, Nov 25, 2008 at 8:24 AM, Reinhard Pötz <re...@apache.org> wrote:
>>> Grzegorz Kossakowski wrote:
>
> Could you elaborate on your caching requirements?
>
We run an Intranet web app, (not a web site) with very complex
dynamically assembled screens. We have fairly long pipelines, with a
lot of aggregated components. There is almost always one component
that cannot be cached at all (or makes little sense to cache) and the
others have varying cache lifetimes. So currently we need to be able
to pull cached SAX streams from the nonchanging components and run the
results through XSLT as per standard Cocoon aggregated validity type
checking.
Any next gen version of our app will likely attempt to move this to a
more granular approach using AJAX on the front end so it should be
possible to eliminate most of, if not all of, the requirement for
aggregated SAX via XSLT. However, even then, for a large chunk of our
data we don't know exactly what can be shared until we examine
security policies that are determined dynamically (eg, based on
previous data requests) so we know we cannot move everything to http /
web server type caching. Similarly, our cache invalidation policies
are complex with hierarchies of dependencies so again you can't set
simple http type cache expiiry policies, you've got to have something
more like the current cocoon validity checking, where we can trigger a
cascade of cache invalidation when some fundamental resource is
updated.
If that raises more questions than it answers I can attempt to elaborate...
--
Peter Hunsberger
Re: Where is Cocoon 3 going to?
Posted by Reinhard Pötz <re...@apache.org>.
Peter Hunsberger wrote:
> On Tue, Nov 25, 2008 at 8:24 AM, Reinhard Pötz <re...@apache.org> wrote:
>> 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.
>>
>>> It's not my intention to criticize anyone but I really think it's not
>>> enough to make others excited and willing to contribute. At least it
>>> looks that way...
>> 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.
>> 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.
>>
>>> 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.
>>
>> 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?
>>
>
> FWIW, we'll be taking a hard look at moving to Cocoon 3 vs. 2.2 as we
> look at migrating off of 2.1. Our main requirement really is for XML
> and XSL pipelines and we don't use most of the existing Cocoon
> infrastructure, the big thing currently lacking is 3 that we really
> need is caching...
Could you elaborate on your caching requirements?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: Where is Cocoon 3 going to?
Posted by Peter Hunsberger <pe...@gmail.com>.
On Tue, Nov 25, 2008 at 8:24 AM, Reinhard Pötz <re...@apache.org> wrote:
> 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.
>
>> It's not my intention to criticize anyone but I really think it's not
>> enough to make others excited and willing to contribute. At least it
>> looks that way...
>
> 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.
> 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.
>
>> 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.
>
> 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?
>
FWIW, we'll be taking a hard look at moving to Cocoon 3 vs. 2.2 as we
look at migrating off of 2.1. Our main requirement really is for XML
and XSL pipelines and we don't use most of the existing Cocoon
infrastructure, the big thing currently lacking is 3 that we really
need is caching...
--
Peter Hunsberger