You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/12/02 18:59:32 UTC
[RT][long] Cocoon 3.0: the necessary mutation
Hi all,
For many years, I have been more than happy with Cocoon, enjoying the
power and ease it brought for both publication and webapp projects. Over
the last months however, other feelings have emerged: there are things
that are definitely overly complex in Cocoon, and there have been some
emerging frameworks leading to "wow, cool!" reactions rather than "yeah,
yet another one". Also, I strongly believe that the Ajax revolution is
quickly obsoleting the traditional reload-page-on-user-action model that
prevailed on the web up to recently and requires frameworks that help
building these new kinds of applications.
All this to say that if we want Cocoon to have a bright future, it must
go through a mutation. This RT dumps my current ideas about this,
depicting something that IMO better fits today's needs while taking into
account many years of innovation and what we learned from them.
-- oOo --
First of all, let's consider the place where Cocoon fits in the large
family of webapp development frameworks.
On one end, we have pure-J2EE things like Struts or JSF. They lead to
writing a lot of Java classes, lots of XML config files, and try/fail
cycles require compile/deploy/restart, even if some tools ease the task.
Despite their heavyweight development process, they are widely accepted
in large companies, both because the J2EE stamp pleases managers and
because of the vast number of entreprise-grade libraries available.
On the other end, we have scripted frameworks like Ruby on Rails,
Django[1], etc. The try/fail cycle is basically save/reload, and writing
simple stuff is very fast because of the use of convention over
configuration and runtime generation of data models (e.g. through
database introspection). Now recent comments[2] show that going beyond
the basic stuff may not be that easy.
Cocoon actually sits in the middle of this spectrum:
- it's a Java servlet and can therefore use almost anything that's
written in Java. The contents of our blocks show this well! As such it
is somehow J2EE compliant and can be deployed in large companies, even
if we have to convince managers that it's better than Struts.
- it's a scripted framework: sitemap, XSL, templates, flowscript. Save
and reload! And this goes further in 2.2 with auto reloading and
compiling classloaders.
So theoretically, Cocoon could be the "RoR of J2EE". Now in its current
incarnation it won't. The learning curve is too steep, some
architectural choices imposed by Cocoon actually go in the way of
developers with the new emerging development practices, and 5 years of
legacy led to a rather confusing picture, with tons of legacy components
and many inconsistencies.
Now Cocoon has also introduced a number of super-cool features and
innovations that definitely make sense, but in a more lightweight and
consistent environment.
So let's draw a picture of what could be Cocoon 3.0. I use a major
version as the ideas outlined below are more than likely to require a
code base, even if many code snippets can be reused from the current code.
-- oOo --
Giving its real role to the controller
--------------------------------------
When we introduced flowscript, we decided that <map:pipeline> should be
the central switchboard through which *all* request go, and introduced
<map:call function>. This leads most webapps written in Cocoon to have
their sitemap starting with something like:
<map:match pattern="do_*">
<map:call function="do_{1}"/>
</map:match>
Why in hell do we have to go through the sitemap to call a function and
then go back to the sitemap through cocoon.sendPage()? This not only
clutters up the sitemap with cut'n pasted snippets, but also makes the
flowscript a second-zone citizen in the application.
So I think we should change a bit the semantics of the sitemap and the
priorities of its various components:
- the sitemap is the configuration of the overall request processing of
the application (or a subpart of it in the case of mounts). It defines
the configuration of that request processing, which is composed of
components (<map:components>), controllers (<map:flow>) and views
(<map:pipeline>). And I even think these 3 parts should really be split
in different files, i.e. moving components to a xconf and pipeline
definitions to e.g. "pipelines.xml".
- the processing flow in a sitemap goes *first* in the controller if
there is one, and *second* in the view. Going to a <map:pipeline> to
call back a function should really be an exceptional case, or even
forbidden.
- since it's no more called by the sitemap, the controller defines a
single entry point, such as "process()". A builtin default
implementation provides an equivalent to <map:call
function="public_{request:sitemapURI}"/>, thus automatically publishing
any public_xxx flowscript function. This is similar to
HttpServlet.service() that calls doGet(), doPost(), etc depending on the
HTTP method but still allows overloading service().
- to allow sophisticated implementations of process() where needed, the
matchers and selectors are made available to the controller, so that
they can check the request environment as easily as the pipeline
statements in sitemap.xmap (also have a look at the Django
dispatcher[3]). This can allow to write something like:
var match = cocoon.matchers.wildcard("admin/*");
if (match) {
if (authenticateAdmin()) {
// call the function named by the '*'
adminServices[match[1]]();
} else {
forbidden();
}
}
- calling cocoon.sendPage(uri) directly goes to the <map:pipeline>
section of the sitemap, to build a view. This seems obvious, but has an
interesting side-effect: there is no more need to invent a private URL
space such as "view-*" to have a two-step processing (controller/view)
of the requests. We can even say that "cocoon.sendPage(null)" calls the
sitemap with the current request URI untouched.
Note: the controller examples in this RT are written in JavaScript, but
JavaFlow should be considered on an equal ground, as Coocon's user base
is two-sided, composed of people coming from the webdesign/php world,
and others coming from the J2EE world. Also, JavaFlow should be the
language of choice for builtin reusable helper controllers.
-- oOo --
Expression languages
--------------------
Do you know how many expression languages there are in Cocoon? Java,
JavaScript, XPath, XReporter, JEXL, etc. There's also all the
micro-languages defined by each of the input modules: many of them use
XPath, but not all...
Also, the way to access a given data is not the same in the sitemap
(e.g. "{request-param:foo}") and in JXTG
("${cocoon.request.getParameter('foo')}" or even
"#{$cocoon/request/parameters/foo}")
We should restrict the number of languages to the useful minimum, and
ensure they can be used consistently everywhere. This useful minimum
looks to me as being JavaScript, XPath and Java (using Janino[4]).
As for the syntax, I think we should use the simple "{..}" notation,
with no initial character. To choose among the 3 expression languages,
we have to choose a default one, and use prefixed expressions for the
other ones. I consider JS to me the most versatile and thus to be the
default language.
That means we'll have "{cocoon.request.remoteHost}" or
"{xpath:$cocoon/request/remoteHost}" or
"{java:cocoon.getRequest().getRemoteHost()}".
About XPath, I'm a bit skeptical wrt its actual usefullness with non-XML
objects, which often looks weird. However, we need to be able to call
XPath on DOM parts of a non-DOM data model, e.g.
"{xpath(cocoon.session.attributes.userDoc, '/meta/dc:title')}". And
interstingly this sample shows that a namespace prefix table must be
available in the expression context for *all* languages.
All this also means that we need a well-defined "cocoon" object defined
identically in all contexts. Additional top-level objects can be
available to provide context-specific data, such as "flow.sendPage()",
"sitemap.resolve('../1')" or "template.consumer".
-- oOo --
Content-aware pipelines
-----------------------
Cocoon 1 had a DOM-based processing, meaning transformations could be
chosen according to the pipeline content. Cocoon 2, when switching to
SAX-based streamed pipelines, abandoned this ability. This hasn't been a
real problem for a long time, as datasources were mostly passive
documents of a well-known structure.
Now things have changed a lot, and we have to deal with heterogeneous
data types and content-driven processing. Let's take some real-life
examples:
- Content syndication: a feed's URL can provide RSS 0.9, 1.0, 2.0 or
Atom. How can we decide what processing has to be applied on a feed if
we don't know what's inside?
- Forrest's infamous SourceTypeAction[5] identifies a document's type
using pull parsing
- SOAP requests: why is SOAP so badly integrated with Cocoon? We
basically need to delegate to Axis that will then call a Java class. Why
so? Because we're unable to choose the service to be called depending on
the request's content.
- finally, the ESB buzz is turning into real projects, and requires
content-based routing of messages.
There were some proposals to implement content-aware selectors[6] but
they never materialized because of the impedance mismatch between a SAX
stream and the usage of DOM (so Cocoon-1-ish!) that was proposed to
implement them.
Now Forrest's SourceTypeAction shows us the way: pull parsing.
So let's switch pipelines from SAX push to StAX pull (JSR 173, see[7]).
Content-aware matchers and selectors can then grab just the amount of
information they need from the pipeline to make their decision. And
contrarily to the SourceTypeAction that requires to resolve the source 2
times (once for pull, once for push), the pipeline engine can
transparently buffer the StAX events consumed by matchers and selectors
to replay them in the next pipeline component.
Using pull pipelines doesn't mean we have to trash everything.
Converting DOM to/from StAX is straightforward, and so is StAX->SAX. The
SAX->StAX conversion is less easy and requires either buffering or a
separate thread.
Using pull pipelines also has an interesting side effects on
aggregations, as they can easily be inlined by pulling events
successively from partial pipelines (i.e. without a serializer), e.g:
<map:aggregate element="root">
<map:part>
<map:generate src="header.xml"/>
<map:transform src="header2html.xsl"/>
</map:part>
<map:part src="content/{1}.xml"/>
</map:aggregate>
<map:transform src="layout.xsl"/>
<map:serialize/>
Actually, writing
<map:part src="foo"/>
is equivalent to writing
<map:part>
<map:generate type="file" src="foo"/>
</map:part>
-- oOo --
Dynamic pipelines
-----------------
Yes, you read it well: dynamic pipelines. This is what comes next
naturally after content-aware pipelines: with use cases like webservices
and ESBs, the content-based routing is not enough and we also need
controller-driven routing.
For simpler cases, we already have cocoon.processPipelineTo() (and the
more versatile PipelineUtils class), but having to call the sitemap and
invent a private URL just to perform a transformation is really overkill.
I'd like to be able to write the following in a flowscript:
var pipeline = flow.newPipeline("non-caching");
pipeline.setGenerator("stream");
pipeline.addTransformer("xslt", "normalize.xsl");
if (cocoon.matchers.xpath("/foo/bar[@id = '" +
cocoon.session.attributes.bar_id + "']", pipeline)) {
handleBar(pipeline);
} else {
wrongId();
}
What we can see above is that we don't even need a serializer for the
pipeline to be useful, as we can pull events from it as soon as it has a
generator. And that generator could well be another pipeline built
somewhere else.
Basically, the pipeline engine becomes a very general-purpose object
that can be used not only in the sitemap (to build views), but also in
the controller for content-driven business logic decisions.
This programmatic building of pipelines can also be used by Cocoon
components themselves to implement some built-in transformations, e.g.
converting an XMLSchema to a CForms definition, without requiring to
copy/paste the corresponding sitemap instructions in user sitemaps, of
requiring to call a system-defined sitemap. IMO, the lack of reusable
system pipelines is one of the reasons why there hasn't been many
off-the-shelf products or applications built on top of Cocoon.
Being able to directly use pipelines can also ease the integration of
Cocoon as a transformation engine in other environments, such as an
advanced message transformer in the ServiceMix ESB[8].
-- oOo --
Controller-driven responses
---------------------------
The advent of Ajax applications leads to a radical change in web
applications architectures. There are many requests that don't lead to
producing a view, but sending data and/or control information. Having to
call a pipeline for this is really useless and overkill, as we don't
need any kind of processing.
We therefore need the controller to be able to directly send a
non-processed response. We already have an example of this in the Ajax
stuff for CForms[9] to send a simple <bu:continue> when form interaction
is finished and a full page reload is needed. Another example is data
transmission with an Ajax client using JSON[10].
So we need additional "sendxxx" methods in the controller: sendText(),
sendObject(), sendBytes() and why not sendStream().
Ajax applications also require aggregations defined at the controller
level. Let's consider an Ajax shopping cart application: the page
displays the items catalogue and a sidebar with the current content of
the shopping cart. When the user browses the items, only the catalogue
area needs to be refreshed on the page. When he adds an item to the
cart, both areas need to be refreshed at once to show the updated cart.
The knowledge of what parts of the page need to be refreshed is in the
controller. A solution can be to call a pipeline that will generate an
XInclude that itself will call other pipelines, but that's smelly and
doesn't allow to give different view data to each of the pipelines.
To allow this, we need something like:
flow.sendMultiple(
["catalogue", { paginator: paginator }],
["cart-sidebar", { cart: cart }]
);
-- oOo --
Core components
---------------------
Moving to pull pipelines isn't the only important core change: we need
to move away from Avalon for good. Now what container will we use? We
don't care: Cocoon 3.0 will be written as POJOs, and will come with a
"default" container. Will it be Spring, Hivemind, Pico? I don't know. We
may even provide configurations for several containers, as does
XFire[xxxxx].
-- oOo --
Ok, thanks reading so far.
My impression is that with all these changes, Cocoon will be sexy again.
Add a bit of runtime analysis of databases and automatic generation of
CForms to the picture, and you have something that has the same
productivity as RoR, but in a J2EE environment. It also includes what I
learned when working on Ajax and the consequences it has on the overall
system architecture.
You certainly have noticed that the above is more about the controller
than about the sitemap. This is because not much changes are needed
there, except content-aware matchers and selectors. But a more featured
controller will allow to trash a great number of pipeline components
that were invented to circumvent controller limitations. The code base
will shrink.
There are also a number of simplifications that can be done by using
builtin conventions over configuration, but I'll write about this later.
Tell me your thoughts. Am I completely off-track, or do you also want to
build this great new thing?
Sylvain
[1] www.djangoproject.com/
[2] http://www.andrewsavory.com/blog/archives/000976.html
[3] http://www.djangoproject.com/documentation/url_dispatch/
[4] http://www.janino.net/
[5]
http://svn.apache.org/repos/asf/forrest/trunk/main/java/org/apache/forrest/sourcetype/SourceTypeAction.java
[6] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101554683923592&w=2
[7] http://stax.codehaus.org/
[8] http://servicemix.codehaus.org/
[9]
http://svn.apache.org/repos/asf/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/flow/javascript/Form.js
[10] http://bluxte.net/blog/2005-11/17-49-57.html
[11] http://xfire.codehaus.org/
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Stefano Mazzocchi <st...@apache.org>.
Luca Morandini wrote:
> Stefano Mazzocchi wrote:
>> Luca Morandini wrote:
>>
>>> Nevertheless, it is easier to build a tool around a declarative
>>> language expressed as XML, than a procedural language expressed as...
>>> a procedural programming language.
>>
>> I'm sorry, Luca, but I think that's BS.
> <cut/>
>> For example, do you think that if the java classes were expressed as
>> XML statements that *declarative* describe their methods and variables
>> and inner classes it would be easier to write a tool like Eclipse?
>
> That I don't know, I've never seen the inner workings of Eclipse.
>
> Let's just say that when something is written in XML (say, an UML model
> expressed as XMI) I can fire up Xalan and beat the beast into submission
> easily, if the same mopel was expressed as a set of Java classes...
> hmmm... time for "man yacc" ?
>
> Maybe it's just that I've worked with XML for too long, but I still like
> the easy production/validation/transformation of vocabularies that comes
> with it, and I'm scared a bit by the other approach.
Which is fair, but this is due to your experience and knowledge. It's
fair and nice that you say that it's easier for *you* to write some code
using XML technologies instead of using javacc or yacc or bison or
whatever else, but using this is an absolute argument is utterly
misleading and one of the sins that, myself included, we, as a community
made over the years.
--
Stefano.
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Torsten Curdt <tc...@apache.org>.
>>> Nevertheless, it is easier to build a tool around a declarative
>>> language expressed as XML, than a procedural language expressed
>>> as... a procedural programming language.
>> I'm sorry, Luca, but I think that's BS.
> <cut/>
>> For example, do you think that if the java classes were expressed
>> as XML statements that *declarative* describe their methods and
>> variables and inner classes it would be easier to write a tool
>> like Eclipse?
>
> That I don't know, I've never seen the inner workings of Eclipse.
>
> Let's just say that when something is written in XML (say, an UML
> model expressed as XMI) I can fire up Xalan and beat the beast into
> submission easily, if the same mopel was expressed as a set of Java
> classes... hmmm... time for "man yacc" ?
Easier development should not out-weight easier usage. But as long as
there is a grammar for creating an AST it is a piece of cake anyway.
> Maybe it's just that I've worked with XML for too long, but I still
> like the easy production/validation/transformation of vocabularies
> that comes with it, and I'm scared a bit by the other approach.
Don't be :)
cheers
--
Torsten
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Luca Morandini <lm...@ieee.org>.
Stefano Mazzocchi wrote:
> Luca Morandini wrote:
>
>> Nevertheless, it is easier to build a tool around a declarative
>> language expressed as XML, than a procedural language expressed as...
>> a procedural programming language.
>
> I'm sorry, Luca, but I think that's BS.
<cut/>
> For example, do you think that if the java classes were expressed as XML
> statements that *declarative* describe their methods and variables and
> inner classes it would be easier to write a tool like Eclipse?
That I don't know, I've never seen the inner workings of Eclipse.
Let's just say that when something is written in XML (say, an UML model
expressed as XMI) I can fire up Xalan and beat the beast into submission
easily, if the same mopel was expressed as a set of Java classes...
hmmm... time for "man yacc" ?
Maybe it's just that I've worked with XML for too long, but I still like
the easy production/validation/transformation of vocabularies that comes
with it, and I'm scared a bit by the other approach.
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Stefano Mazzocchi <st...@apache.org>.
Luca Morandini wrote:
> Nevertheless, it is easier to build a tool around a declarative
> language expressed as XML, than a procedural language expressed as... a
> procedural programming language.
I'm sorry, Luca, but I think that's BS.
A complexity of a tool is given by the degrees of freedom, not by the
flavor/syntax/style that you use to encode the information that your
tool generates.
Sure, XML removes the syntax and validation stages that you get for
free. Then RDF and OWL might even give you some implicit reasoning
abilities. And then an RDF rule language might introduce some
prolog/datalog-like constructs.
And if you think writing a tool for this stuff is easier just because
it's more "declarative" (which more and more reads to me as "the
procedures are implicit"), think again, you are thinking about parser
reuse and *that* is probably 1% of your tool cost anyway.
For example, do you think that if the java classes were expressed as XML
statements that *declarative* describe their methods and variables and
inner classes it would be easier to write a tool like Eclipse?
--
Stefano.
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Luca Morandini <lm...@ieee.org>.
Sylvain Wallez wrote:
> Luca Morandini wrote:
>
>> Generally speaking, in the procedural vs. declarative debate I drifts
>> towards the latter. For example, I see the advantages in using
>> something like Spring Web Flow, not the least of them being the easy
>> development of tools (AndroMDA maybe ?).
>
> If you can roundtrip between a model and a procedural language, then
> tooling is not a problem.
<cut/>
Granted. Nevertheless, it is easier to build a tool around a declarative
language expressed as XML, than a procedural language expressed as... a
procedural programming language.
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Luca Morandini wrote:
> Sylvain Wallez wrote:
>>
>> When we introduced flowscript, we decided that <map:pipeline> should
>> be the central switchboard through which *all* request go,
> <cut/>
>> - the processing flow in a sitemap goes *first* in the controller if
>> there is one, and *second* in the view. Going to a <map:pipeline> to
>> call back a function should really be an exceptional case, or even
>> forbidden.
>
> Hmm... my favorite selling proposition about Cocoon is "look no
> further than the sitemap to know which component answers an URI", and
> this dynamic pipeline concept would shatter this.
>
> Generally speaking, in the procedural vs. declarative debate I drifts
> towards the latter. For example, I see the advantages in using
> something like Spring Web Flow, not the least of them being the easy
> development of tools (AndroMDA maybe ?).
If you can roundtrip between a model and a procedural language, then
tooling is not a problem. I've been using this approach for 10 years
starting in 1990 with a pre-OO design method used in the space
industry[1]. We had a tool that was generating Ada or C code from
graphical models, containing special markers around code sections that
could be changed directly in the code.
We wrote hundreds of thousands lines of code using this technique
without ever using a declarative language interpreter. Just plain Ada
and C. And this without ever loosing our ability to change the program's
structure using graphical tools.
Sylvain
[1] http://www.estec.esa.nl/wmwww/WME/oot/hood/
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Luca Morandini <lm...@ieee.org>.
Sylvain Wallez wrote:
>
> When we introduced flowscript, we decided that <map:pipeline> should be
> the central switchboard through which *all* request go,
<cut/>
> - the processing flow in a sitemap goes *first* in the controller if
> there is one, and *second* in the view. Going to a <map:pipeline> to
> call back a function should really be an exceptional case, or even
> forbidden.
Hmm... my favorite selling proposition about Cocoon is "look no further
than the sitemap to know which component answers an URI", and this
dynamic pipeline concept would shatter this.
Generally speaking, in the procedural vs. declarative debate I drifts
towards the latter. For example, I see the advantages in using something
like Spring Web Flow, not the least of them being the easy development
of tools (AndroMDA maybe ?).
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Guido Casper <gc...@s-und-n.de>.
The subject line and Gianugo's comment caused me to interrupt my silence :-)
Gianugo Rabellino wrote:
> Starting from our mistakes, today I tend to say that one of the areas
> where we have completely failed is the idea of not-so-technical people
> managing the applications:
I agree and I think it's an important point to emphasize. I still
remember the term "pyramid of contracts" (PoC). And I'm still a believer.
It may be that it needs some modification from its original definition.
But I'm wholeheartedly convinced that "the world" needs such a thing
more than ever before.
AFAIK RoR was a byproduct from building an application from scratch
(although I'm not entirely sure wether that really is an indication of
the above statement).
Cocoon today to me is a tool for deveopers by developers. It is a
brilliant webframework with a lot of leading innovations. But if its
major goal is exactly that: being the most productive webframework (I
know - it is a lot of other things - XML processing framework, etc.)
than that's a goal A LOT OF other projects are trying to achieve as
well. So there is always a certain chance that we are being
"out-innovated". I'm not saying this is a bad thing. It is one of the
things that drives us. I'm just stating a fact to make my point clear.
But we should be aware that a consequence of it is, that we will always
try to compete with all these other projects.
What is our strength? What is Cocoon's real potential? What is our
elevator pitch (sorry for that one :-)?
I think a major cause for our failing to deliver the PoC is Cocoon's low
adoption. If Cocoon's adoption were like Struts I'm sure there would be
more users expressing the need for it (if provided with such options
that is, but I may be wrong of course).
But aren't the recent screams for simplicity, fun/sexy and productivity
exactly that? Shoudn't we just put this screams into perspective?
Different skill levels have different perception of what is simple or
fun/sexy or even productive.
All I'm asking for is to consider what we want Cocoon 3.0's major goals
to be. If it's to be the best tool for talented developers building
webapplications that's perfectly fine. That's just where Cocoon has been
driven by evolution and the most committed people (and that may be a
sign the PoC is not really needed/useful). A common coherent vision may
be elusive, but I thought it doesn't harm to explicitely state possible
future directions. I think the other goals: simplicity, fun/sexy,
productivity may be easier to unite.
Although I have the slight feeling that such a discussion may be doomed
to lead to nowhere I thought the subject of Cocoon 3.0 would justify it.
I hope you agree and bare with me :-)
Guido
--
Freundliche Grüße / With kind regards
Guido Casper
S&N AG
Competence Center Open Source
Klingenderstr. 5
D 33100 Paderborn
voice +49 5251/1581-87
fax +49 5251/1581-71
eMail gcasper@s-und-n.de
Web http://www.s-und-n.de
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Actually, with the pipeline API, the ability to expand aggregations
> inline and virtual pipeline components, I'm wondering if we still need
> the "cocoon:" protocol at all.
Wrote too fast: yes, we still need "cocoon:", otherwise XInclude becomes
rather useless, and serving an aggregated page while still giving direct
access to its part really won't be practical.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Gianugo Rabellino wrote:
> On 12/2/05, Sylvain Wallez <sy...@apache.org> wrote:
>
>
>> All this to say that if we want Cocoon to have a bright future, it must
>> go through a mutation. This RT dumps my current ideas about this,
>> depicting something that IMO better fits today's needs while taking into
>> account many years of innovation and what we learned from them.
>>
>>
>
> Thanks *so* much for this, Sylvain. Your words echo what I've been
> thinking from a long time: Cocoon is a great framework with lots of
> unexpressed potential, and I definitely think that in this stage of
> our lives, we need a revolution much more than an evolution. All the
> latest and greatest in Cocoon development lately have been little more
> than finding solutions to our own problems, instead than questioning
> ourselves with the idea of changing perspectives and seeing the real
> problems. A perfect example, to me, is the whole block scenario: over
> the last few months I came to realize that if we need such a
> sophisticated beast to manage our complexity, this means that we are
> just too complex, period.
>
> So, back to the revolution scenario, I'd love to throw my pebbles in
> the lake and see if they can be of any use: first of all, I don't
> really believe that the situation to our problems can happen via
> evolution (say 2.x stuff): if you look at what people is expecting
> today, you'll notice how things might be best accomplished by a clean
> slate approach, which takes issues such as backward compatibility with
> a grain of salt, being ready to deal with it, swallow the idea of
> either sticking to 2.x (which will still be around for a long time) or
> rewrite good portions of what you've got and be done with it. If we
> are to revolutionize, well, this is a good time to have a look at the
> war we have been fighting and the battles we won and lost, in order to
> learn from our mistakes.
>
> Starting from our mistakes, today I tend to say that one of the areas
> where we have completely failed is the idea of not-so-technical people
> managing the applications: we had been figuring out, in our little SOC
> world, that people would have written bits of functionality, with
> management tying them into sitemaps. The equation
> non-technical-people=XML files would have worked like a charm, but
> what's actually happening is that sitemaps are strongly in the
> developer's domain, and developers aren't that comfortable with angle
> brackets and bloated syntaxes. The next incarnation of the sitemap,
> whatever that's going to be, must be as developer-friendly as
> possible, which means concise and effective, something we don't really
> have today.
>
That's where dynamic pipelines, i.e. a programmatic access to pipelines,
can be of great help.
> The second point I hate most in today's Cocoon is the TIMTOWDI effect.
> Cocoon applications, written with no discipline, unfortunately can be
> as messy as Perl or even worse: everytime I'm faced with a new
> Cocoon-based app I tend to have a way too hard time understanding what
> the flow is like and which components are used in what order:
> component declaration, private pipeliens, actions, mounts and the
> cocoon:/ protocol tend to get too much in the way of a developer, and
> I'd love to see it changed. True, there is no need to look any further
> than the sitemap to see what happens (well, flow changed the picture
> quite a bit there), but is the sitemap is a tangled mess, this is of
> little help.
>
Actually, with the pipeline API, the ability to expand aggregations
inline and virtual pipeline components, I'm wondering if we still need
the "cocoon:" protocol at all.
<snip/>
> +1 for a POJO based Cocoon, not sure about container replaceability
> (tends to be an Holy Grail nowadays).
>
Right. Let's keep the POJO thing and provide integration with a single
container, but still allowing people to use another one if they have the
need to. Practically, that means avoiding at all costs dependencies of
the code on the container. Pure POJOs may not always be practical
(thinking mainly here about component selectors), and in that case we
must define our own lightweight abstractions that fit our needs and
bridge to the actual container.
>> My impression is that with all these changes, Cocoon will be sexy again.
>>
>
> A few words about the "sexy" stuff which has been perceived
> differently in the responses so far: we need sexy stuff if we want to
> have an healthy, diverse and growing community. Sexyness and adoption
> generally go hand in hand.
>
Yup.
>> Add a bit of runtime analysis of databases and automatic generation of
>> CForms to the picture, and you have something that has the same
>> productivity as RoR, but in a J2EE environment. It also includes what I
>> learned when working on Ajax and the consequences it has on the overall
>> system architecture.
>>
>
> Don't forget tools! In Cocoon 2.x it's basically impossible to provide
> decent productivity tools because there are too many components with
> contracts being too loose. If Cocoon 3 has to happen, this is one of
> the points I will tend to commit myself to, ensuring that every
> functionality can be easily managed, deployed and monitored (JMX,
> anyone?) and that those mundane and boring tasks that affect a Cocoon
> developer's life can be done using some fancy web interface or an IDE.
>
JDK 1.5 has a JMX console and AFAIU Spring allows to easily JMX-ify
beans. So that may come for free.
>> Tell me your thoughts. Am I completely off-track, or do you also want to
>> build this great new thing?
>>
>
> I'm with you with all my CFT
CFT ???
> Hope to talk about all this with some fellow Cocooners next week in San Diego.
>
Yep. An intersting discussion subject :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.12.2005 17:11, Gianugo Rabellino wrote:
> Don't forget tools! In Cocoon 2.x it's basically impossible to provide
> decent productivity tools because there are too many components with
> contracts being too loose.
+1
I guess this is not only a problem for providing tools but for Cocoon in
general. On which part of Cocoon can you rely? It seems there are only
the sitemap and the sitemap component interfaces. Not much to be
supported by tools ... So either Cocoon must more follow standard ways
or really *define* its own standards. See how fast Spring evolved. This
could only happen as a result of its easy "interface", the bean
configuration and the Java bean standard (setters/getters).
Jörg
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Gianugo Rabellino <gi...@gmail.com>.
On 12/2/05, Sylvain Wallez <sy...@apache.org> wrote:
> All this to say that if we want Cocoon to have a bright future, it must
> go through a mutation. This RT dumps my current ideas about this,
> depicting something that IMO better fits today's needs while taking into
> account many years of innovation and what we learned from them.
>
Thanks *so* much for this, Sylvain. Your words echo what I've been
thinking from a long time: Cocoon is a great framework with lots of
unexpressed potential, and I definitely think that in this stage of
our lives, we need a revolution much more than an evolution. All the
latest and greatest in Cocoon development lately have been little more
than finding solutions to our own problems, instead than questioning
ourselves with the idea of changing perspectives and seeing the real
problems. A perfect example, to me, is the whole block scenario: over
the last few months I came to realize that if we need such a
sophisticated beast to manage our complexity, this means that we are
just too complex, period.
So, back to the revolution scenario, I'd love to throw my pebbles in
the lake and see if they can be of any use: first of all, I don't
really believe that the situation to our problems can happen via
evolution (say 2.x stuff): if you look at what people is expecting
today, you'll notice how things might be best accomplished by a clean
slate approach, which takes issues such as backward compatibility with
a grain of salt, being ready to deal with it, swallow the idea of
either sticking to 2.x (which will still be around for a long time) or
rewrite good portions of what you've got and be done with it. If we
are to revolutionize, well, this is a good time to have a look at the
war we have been fighting and the battles we won and lost, in order to
learn from our mistakes.
Starting from our mistakes, today I tend to say that one of the areas
where we have completely failed is the idea of not-so-technical people
managing the applications: we had been figuring out, in our little SOC
world, that people would have written bits of functionality, with
management tying them into sitemaps. The equation
non-technical-people=XML files would have worked like a charm, but
what's actually happening is that sitemaps are strongly in the
developer's domain, and developers aren't that comfortable with angle
brackets and bloated syntaxes. The next incarnation of the sitemap,
whatever that's going to be, must be as developer-friendly as
possible, which means concise and effective, something we don't really
have today.
The second point I hate most in today's Cocoon is the TIMTOWDI effect.
Cocoon applications, written with no discipline, unfortunately can be
as messy as Perl or even worse: everytime I'm faced with a new
Cocoon-based app I tend to have a way too hard time understanding what
the flow is like and which components are used in what order:
component declaration, private pipeliens, actions, mounts and the
cocoon:/ protocol tend to get too much in the way of a developer, and
I'd love to see it changed. True, there is no need to look any further
than the sitemap to see what happens (well, flow changed the picture
quite a bit there), but is the sitemap is a tangled mess, this is of
little help.
Now, on to some specific answers:
> Giving its real role to the controller
> --------------------------------------
<snip/>
> - the sitemap is the configuration of the overall request processing of
> the application (or a subpart of it in the case of mounts). It defines
> the configuration of that request processing, which is composed of
> components (<map:components>), controllers (<map:flow>) and views
> (<map:pipeline>). And I even think these 3 parts should really be split
> in different files, i.e. moving components to a xconf and pipeline
> definitions to e.g. "pipelines.xml".
A word of caution here: different files tend to mean different hassles
to maintain, test and deploy. What I'd like to see is us moving away
from configuration files as much as possible, providing sensible
defaults and easy way to override them. Be serious about YAGNI and
KISS: in years of Cocoon development I still have to find a real use
case where a subsitemap could use a different implementation of a
component reusing the name that was used elsewhere: having a central
component repository and nothing more could do the same job just fine
and make us forget about the whole <map:components/> nightmare. Not to
mention how easier it would be to provide a configuration tool,
something that has been overdue for ages. My proposal, then, would be
ditching the components altogether, moving their
declaration/configuration to a central location and be done with it.
> Expression languages
> --------------------
>
> Do you know how many expression languages there are in Cocoon? Java,
> JavaScript, XPath, XReporter, JEXL, etc. There's also all the
> micro-languages defined by each of the input modules: many of them use
> XPath, but not all...
>
> Also, the way to access a given data is not the same in the sitemap
> (e.g. "{request-param:foo}") and in JXTG
> ("${cocoon.request.getParameter('foo')}" or even
> "#{$cocoon/request/parameters/foo}")
>
> We should restrict the number of languages to the useful minimum, and
> ensure they can be used consistently everywhere.
Yes, please. Pretty please. Consistency is key.
> All this also means that we need a well-defined "cocoon" object defined
> identically in all contexts. Additional top-level objects can be
> available to provide context-specific data, such as "flow.sendPage()",
> "sitemap.resolve('../1')" or "template.consumer".
A consistent and well documented cocoon object? Boy, I must be dreaming...:-)
> Content-aware pipelines
> -----------------------
Again, BIG +1 here. I'm sorely missing the ability to operate based on
the content being feeded to Cocoon. Now, whether this should be done
using STaX is an interesting subject: I'm all for delving into it, but
SAX compatibility should be taken seriously (for one, XSLT is here to
stay, and today's implementations AFAICT are SAX based). This said, I
love the idea of solving elegantly the issue of buffering events.
> Dynamic pipelines
> -----------------
> Yes, you read it well: dynamic pipelines. This is what comes next
> naturally after content-aware pipelines: with use cases like webservices
> and ESBs, the content-based routing is not enough and we also need
> controller-driven routing.
As we like to say in Italy, you brought your dog to the church. :-)
But apart from then, $DEITY knows how many times I felt the need for a
(controlled) dynamic pipeline scenario so no problem here. However,
what you're suggesting as a possible implementation, also has an
interesting side effect which relates to what Bertrand has commented,
about being able to use Cocoon as an API for different scenario:
again, something that has been for a long time in my wishlist. OTOH, I
see some problems in giving too much flexibility away, so some care
should be taken.
> Core components
> ---------------------
>
> Moving to pull pipelines isn't the only important core change: we need
> to move away from Avalon for good. Now what container will we use? We
> don't care: Cocoon 3.0 will be written as POJOs, and will come with a
> "default" container. Will it be Spring, Hivemind, Pico? I don't know. We
> may even provide configurations for several containers, as does
> XFire[xxxxx].
+1 for a POJO based Cocoon, not sure about container replaceability
(tends to be an Holy Grail nowadays).
> My impression is that with all these changes, Cocoon will be sexy again.
A few words about the "sexy" stuff which has been perceived
differently in the responses so far: we need sexy stuff if we want to
have an healthy, diverse and growing community. Sexyness and adoption
generally go hand in hand.
> Add a bit of runtime analysis of databases and automatic generation of
> CForms to the picture, and you have something that has the same
> productivity as RoR, but in a J2EE environment. It also includes what I
> learned when working on Ajax and the consequences it has on the overall
> system architecture.
Don't forget tools! In Cocoon 2.x it's basically impossible to provide
decent productivity tools because there are too many components with
contracts being too loose. If Cocoon 3 has to happen, this is one of
the points I will tend to commit myself to, ensuring that every
functionality can be easily managed, deployed and monitored (JMX,
anyone?) and that those mundane and boring tasks that affect a Cocoon
developer's life can be done using some fancy web interface or an IDE.
> Tell me your thoughts. Am I completely off-track, or do you also want to
> build this great new thing?
I'm with you with all my CFT (just look at the commit logs to see how
much have I got of that in the past few years, but hey... :-)) and,
responding to Bertrand on that topic, I'm not that concerned about
project resourcing: given a good plan, I'm sure we'll find enough
people to attain our goals. Hope to talk about all this with some
fellow Cocooners next week in San Diego.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Thomas Lutz <ma...@gmx.at>.
Sylvain Wallez wrote:
<snip />
> My impression is that with all these changes, Cocoon will be sexy
> again. Add a bit of runtime analysis of databases and automatic
> generation of CForms to the picture, and you have something that has
> the same productivity as RoR, but in a J2EE environment. It also
> includes what I learned when working on Ajax and the consequences it
> has on the overall system architecture.
Hm, I'm not sure how to say this, so that it sounds not too sharp, but
although all the features you described are useful, I don't think they
are enough for a major version. That's more sort of 2.x evolution, not a
3.0 revolution :-)
I would change the order. What makes RoR and some others "sexy" is the
quick start a long with out-of-the-box "databasebrowser" support. So
imho a app-skeleton generator would be really important to make the
cocoon community grow. Just give it a database, hit a button and here's
your fancy new databasebrowser. This would reduce the barriere for
cocoon beginners, too, as they don't have to start from scratch and can
learn by modifying small parts of the components involved....
Some thoughts on this:
-choose a db layer... spring with hibernate for example
-write some code generators, or even better, some kind of a subsitemap,
that generates all files that are not supplied by the developer (if you
want a customized template, write one, if not, take the one generated by
cocoon (on the fly))
-get some fancy widgets for the db browser...
Speaking of widgets... I am not sure if it makes sense to reinvent the
"widgetwheel"... Wouldn't it be better to put some work into the JSF
block, and use myfaces/tomahawk as "cocoon gui" ? Replace the "ugly" JSF
renderkits with cocoon pipelines, and supply "flow" as controller for
JSF ? Not sure about this, but I think this could really rock :-)...
tom
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain,
I must admit that I only skimmed your post but I will go back and
re-read it. But this couldn't come at a more interesting time.
I recently got a new manager from outside the company. His first week
on the job he basically said "Why aren't we using struts. Everybody uses
struts. We should too." Then he talked to some folks in one part of the
company (we bought them a year or two ago) who are doing their own thing
and want to use JSF. So now he thinks JSF is the way to go. If I don't
quit first I am supposed to "re-evaluate" the choice for the
presentation framework.
Frankly, I looked at JSF it didn't see much I liked. But it has one
thing that is appealing and is something that the "other" group insists
they need. A stateful flow controller. They don't want to write
flowscript or javaflow - they just want to configure the application
flow. Frankly, this doesn't seem like too bad of an idea but I just
don't like how JSF does it. From what I saw the forms directly invoke
the actions which horribly mixes the model and the view.
So I did some searching and found Spring webflow. It looks to be
exactly what we need. So I am in the early stages of creating a
WebflowInterpreter using a refactored portion of the JavaInterpreter.
Now this may strike you as somewhat off the topic you were speaking to,
but it occurred to me a while ago that the webflow configuration would
actually be doing the vast majority of the controller logic. The only
thing left in the sitemap would be the pipelines needed to render the
views. And I am in absolute agreement that that is all that should be
in the sitemap.
Ralph
>
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 5 déc. 05, à 18:25, Marc Portier a écrit :
>> ...I guess I just wanted to make sure somebody hears what (I think that)
>> Bertrand is saying ;-)
>
> thanks Marc - my analysis wasn't as detailed as yours, but I like your
> "six-levels stack" concept very much, this is what I was thinking about.
Me too. A layered approach, allowing people to pick up what they need,
and enforcing strict contracts.
Thanks for this great analysis Marc!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 5 déc. 05, à 18:25, Marc Portier a écrit :
> ...I guess I just wanted to make sure somebody hears what (I think
> that)
> Bertrand is saying ;-)
thanks Marc - my analysis wasn't as detailed as yours, but I like your
"six-levels stack" concept very much, this is what I was thinking
about.
-Bertrand
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Marc Portier <mp...@outerthought.org>.
Daniel Fagerstrom wrote:
> Great analysis Marc (and Bertrand)! Getting our core stuff layered and
> reusable should be our main focus. After that we can build all kind of
> great new inovations above it if we feel like it.
>
sure, but more importantly: anyone could!
if you ask me, it's time to cut up the cake and give everyone a piece.
and I surely don't think this is going to divide the community, yeah
maybe there are going to be less people using the full stack as we know
it, but I'ld bet ya there is to be more people that could sit in on the
next gettogether :-)
seriously, I would love if e.g. our sax filtering expertise, and surely
our great concept of the source-resolver could be influencing far more
projects out there (think fop, batik,...) if we can build a bottom stack
that is usefull for all, all (will, well at least) could be building
components that are usefull for cocoon ('s higher layers)
if nothing else, it would probably make it easier to write unit
tests/docs for the lower layers...
regards,
-marc=
> /Daniel
>
> Marc Portier wrote:
>
>> catching up late on this thread, I can't help feeling Bertrand is right
>> on the spot here, so I'm left to wonder why so little people chime in...
>>
>>
>> So include me in the camp of: we shouldn't be thinking of making the
>> whole of cocoon even bigger or more feature-rich... not before we've
>> seriously chopped it down in smaller chuncks that can live in their own
>> right, and can _incrementally_ lure people into the whole...
>>
>>
>> IMHO cocoon already claims territory in all directions,
>> even if that started as convenience to the end-user and is mostly only
>> administrative stuff this is the kind of convenience that not just hides
>> but almost blocks access to the real meat on the bone...
>>
>> this should stop, and be reversed.
>>
>>
>> cocoon's history rephrazed: Cocoon is a nifty XML pipeline-mechanism,
>> hm, might get slow, no wait let me increase performance by creating some
>> smart object pooling framework first, and now: just wait to let me show
>> you how that works in a servlet, yeah well, no wait let me show you how
>> to use that in a web-app with a ready web.xml to cater for encodings and
>> stuff, no wait never mind your servlet container just do cocoon.sh
>> servlet and you're set! So what do you think?
>> Not impressed? Uh, how could that be? Well, wait! Now that we have
>> everything in place we have no limitations to throw in more goodies to
>> really make you dazzle,.. so over time we get continuations, form libs,
>> javaflow, ajax, whatnot...
>>
>> (some of this makes me think about one of the insights I got from
>> reading the CATB looong ago: this moment were Eric realizes his
>> popclient doesn't need to be and MDA *AND* an MTA to be usefull...
>> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s07.html)
>>
>>
>>
>> Ok, so far the whining, if I'ld let myself wonder over what is the
>> incremental path I would guess it to be something like this:
>>
>> 1. start off with jaxp/sax knowledge or die,
>> provide our base of transformers/serializers as (only a minor step
>> above) xmlfilters/contentHandlers
>>
>> 2. throw in the sourceresolver functionality (without the avalon as a
>> requirement) allow it to have flexible registration of new types of
>> sources, let all our 'XMLFilters' in on the play
>>
>> 3. only now throw in the sitemap as a xml-config way to describe your
>> pipes and a way to re-enter the machinery through the cocoon:/ source
>>
>> 4. throw in an extension mechanism (yeah blocks) so more complex
>> pipelines/and ready sitemaps can be reused and build upon each other
>>
>> -- (only) from here we go into web-container land --
>>
>> 5. allow servlet integration through a mix of impedance-mismatch helpers
>> - a standard way (not an own servlet?) to allow people
>> - encoding stuff we've handled here and there
>> - serializers
>> - the context:/ sourcefactory
>> - nifty url inspection/decision stuff (selectors, matchers...)
>>
>> 6. provide a servlet-controller-delegation pattern (now a real servlet,
>> one of the front-controller type) to allow for various actual
>> controllers, and allow those to be managed through fixed url's (actions)
>> instance url's (apples) or conntinuation urls (flowscript/javaflow)
>>
>> 7. build on top a form-framework that eventually brings ajax support
>>
>> blast I didn't even mention the container, seriously: with some many of
>> them out there, why not make our classes just clean, mean and DI ready
>> and allow the use of those?
>>
>>
>> anyway, if cocoon would allow to be used on ALL of these levels, (and
>> not only starting off at 6) then it would be succesful,
>>
>> I would find it logical that the number of users is dropping as you go
>> up in this stack... and it's precisely that effect we are facing now:
>> pushing up in a monolithic way so we become useful for less and less...
>>
>>
>> anyways, I'm jumping in late, and I've been only lurking from the
>> sideline lately...
>>
>> I guess I just wanted to make sure somebody hears what (I think that)
>> Bertrand is saying ;-)
>>
>> regards,
>> -marc=
>
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Great analysis Marc (and Bertrand)! Getting our core stuff layered and
reusable should be our main focus. After that we can build all kind of
great new inovations above it if we feel like it.
/Daniel
Marc Portier wrote:
> catching up late on this thread, I can't help feeling Bertrand is right
> on the spot here, so I'm left to wonder why so little people chime in...
>
>
> So include me in the camp of: we shouldn't be thinking of making the
> whole of cocoon even bigger or more feature-rich... not before we've
> seriously chopped it down in smaller chuncks that can live in their own
> right, and can _incrementally_ lure people into the whole...
>
>
> IMHO cocoon already claims territory in all directions,
> even if that started as convenience to the end-user and is mostly only
> administrative stuff this is the kind of convenience that not just hides
> but almost blocks access to the real meat on the bone...
>
> this should stop, and be reversed.
>
>
> cocoon's history rephrazed: Cocoon is a nifty XML pipeline-mechanism,
> hm, might get slow, no wait let me increase performance by creating some
> smart object pooling framework first, and now: just wait to let me show
> you how that works in a servlet, yeah well, no wait let me show you how
> to use that in a web-app with a ready web.xml to cater for encodings and
> stuff, no wait never mind your servlet container just do cocoon.sh
> servlet and you're set! So what do you think?
> Not impressed? Uh, how could that be? Well, wait! Now that we have
> everything in place we have no limitations to throw in more goodies to
> really make you dazzle,.. so over time we get continuations, form libs,
> javaflow, ajax, whatnot...
>
> (some of this makes me think about one of the insights I got from
> reading the CATB looong ago: this moment were Eric realizes his
> popclient doesn't need to be and MDA *AND* an MTA to be usefull...
> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s07.html)
>
>
> Ok, so far the whining, if I'ld let myself wonder over what is the
> incremental path I would guess it to be something like this:
>
> 1. start off with jaxp/sax knowledge or die,
> provide our base of transformers/serializers as (only a minor step
> above) xmlfilters/contentHandlers
>
> 2. throw in the sourceresolver functionality (without the avalon as a
> requirement) allow it to have flexible registration of new types of
> sources, let all our 'XMLFilters' in on the play
>
> 3. only now throw in the sitemap as a xml-config way to describe your
> pipes and a way to re-enter the machinery through the cocoon:/ source
>
> 4. throw in an extension mechanism (yeah blocks) so more complex
> pipelines/and ready sitemaps can be reused and build upon each other
>
> -- (only) from here we go into web-container land --
>
> 5. allow servlet integration through a mix of impedance-mismatch helpers
> - a standard way (not an own servlet?) to allow people
> - encoding stuff we've handled here and there
> - serializers
> - the context:/ sourcefactory
> - nifty url inspection/decision stuff (selectors, matchers...)
>
> 6. provide a servlet-controller-delegation pattern (now a real servlet,
> one of the front-controller type) to allow for various actual
> controllers, and allow those to be managed through fixed url's (actions)
> instance url's (apples) or conntinuation urls (flowscript/javaflow)
>
> 7. build on top a form-framework that eventually brings ajax support
>
> blast I didn't even mention the container, seriously: with some many of
> them out there, why not make our classes just clean, mean and DI ready
> and allow the use of those?
>
>
> anyway, if cocoon would allow to be used on ALL of these levels, (and
> not only starting off at 6) then it would be succesful,
>
> I would find it logical that the number of users is dropping as you go
> up in this stack... and it's precisely that effect we are facing now:
> pushing up in a monolithic way so we become useful for less and less...
>
>
> anyways, I'm jumping in late, and I've been only lurking from the
> sideline lately...
>
> I guess I just wanted to make sure somebody hears what (I think that)
> Bertrand is saying ;-)
>
> regards,
> -marc=
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Marc Portier <mp...@outerthought.org>.
catching up late on this thread, I can't help feeling Bertrand is right
on the spot here, so I'm left to wonder why so little people chime in...
So include me in the camp of: we shouldn't be thinking of making the
whole of cocoon even bigger or more feature-rich... not before we've
seriously chopped it down in smaller chuncks that can live in their own
right, and can _incrementally_ lure people into the whole...
IMHO cocoon already claims territory in all directions,
even if that started as convenience to the end-user and is mostly only
administrative stuff this is the kind of convenience that not just hides
but almost blocks access to the real meat on the bone...
this should stop, and be reversed.
cocoon's history rephrazed: Cocoon is a nifty XML pipeline-mechanism,
hm, might get slow, no wait let me increase performance by creating some
smart object pooling framework first, and now: just wait to let me show
you how that works in a servlet, yeah well, no wait let me show you how
to use that in a web-app with a ready web.xml to cater for encodings and
stuff, no wait never mind your servlet container just do cocoon.sh
servlet and you're set! So what do you think?
Not impressed? Uh, how could that be? Well, wait! Now that we have
everything in place we have no limitations to throw in more goodies to
really make you dazzle,.. so over time we get continuations, form libs,
javaflow, ajax, whatnot...
(some of this makes me think about one of the insights I got from
reading the CATB looong ago: this moment were Eric realizes his
popclient doesn't need to be and MDA *AND* an MTA to be usefull...
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s07.html)
Ok, so far the whining, if I'ld let myself wonder over what is the
incremental path I would guess it to be something like this:
1. start off with jaxp/sax knowledge or die,
provide our base of transformers/serializers as (only a minor step
above) xmlfilters/contentHandlers
2. throw in the sourceresolver functionality (without the avalon as a
requirement) allow it to have flexible registration of new types of
sources, let all our 'XMLFilters' in on the play
3. only now throw in the sitemap as a xml-config way to describe your
pipes and a way to re-enter the machinery through the cocoon:/ source
4. throw in an extension mechanism (yeah blocks) so more complex
pipelines/and ready sitemaps can be reused and build upon each other
-- (only) from here we go into web-container land --
5. allow servlet integration through a mix of impedance-mismatch helpers
- a standard way (not an own servlet?) to allow people
- encoding stuff we've handled here and there
- serializers
- the context:/ sourcefactory
- nifty url inspection/decision stuff (selectors, matchers...)
6. provide a servlet-controller-delegation pattern (now a real servlet,
one of the front-controller type) to allow for various actual
controllers, and allow those to be managed through fixed url's (actions)
instance url's (apples) or conntinuation urls (flowscript/javaflow)
7. build on top a form-framework that eventually brings ajax support
blast I didn't even mention the container, seriously: with some many of
them out there, why not make our classes just clean, mean and DI ready
and allow the use of those?
anyway, if cocoon would allow to be used on ALL of these levels, (and
not only starting off at 6) then it would be succesful,
I would find it logical that the number of users is dropping as you go
up in this stack... and it's precisely that effect we are facing now:
pushing up in a monolithic way so we become useful for less and less...
anyways, I'm jumping in late, and I've been only lurking from the
sideline lately...
I guess I just wanted to make sure somebody hears what (I think that)
Bertrand is saying ;-)
regards,
-marc=
Bertrand Delacretaz wrote:
> Le 4 déc. 05, à 11:27, Sylvain Wallez a écrit :
>
>> Bertrand Delacretaz wrote:
>>
>>> ....In the meantime, maybe offering an embeddable version of your
>>> "dynamic pipelines" thing would be a great help in getting more
>>> people to use the unique things that Cocoon has to offer. But it's a
>>> much smaller vision than yours ;-)
>>
>>
>> Yes, but that can be the first step: define this pipeline API and the
>> minimal amount of components for it to be usable (a parser, an XSLT
>> and XInclude transformer and a bunch of serializers), and build on it.
>> Doing it that way can also ensure this pipeline API is kept
>> independent from the surrounding front-end, be it flowscript, Spring
>> webflow or an ESB engine....
>
>
> I like this as an initial vision for Cocoon 3.0: take a small part of
> what we have that is really unique (XML processing pipelines), and
> repackage it as a small POJO-based thing that people can use in
> different contexts.
>
> I've thought a bit more about your RT, and I think the single most
> important thing in ensuring a future for Cocoon and the community is
>
> ** We need to play better with others **
>
> We have some great things (Pipelines, Forms, Flow as an innovative way
> of glueing java components together, Continuations) but to use them
> people have to commit to Cocoon as a whole. It's a big decision, and
> considering the amount of (justified) uncertainty about Java's future as
> an application language, I think less people will make this decision in
> the next year.
>
> I think being able to deliver our good things in smaller embeddable
> packages would make a big difference: people can then pick what they
> need from Cocoon yet continue working with the tools that they're used to.
>
> If the overall Cocoon offering is useful to them, they might switch
> completely later on, but at first they'd just use parts of Cocoon within
> their existing environment, and start to love them because they're
> useful to them, not because we told them to love these things (which is
> what we're trying to do currently, with little success).
>
> As a nice side effect, such a structure would *force* clean modularity
> on us.
>
> So my conclusion is: the mutation that we need is towards embeddable
> POJOs, which allow our unique stuff to be reused elsewhere, in small
> packages.
>
> The dream of having the Java applications world switch to Cocoon is
> over, yet we have many cool things to offer - this is an opportunity to
> broaden the use of these cool things.
>
> -Bertrand
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 déc. 05, à 11:27, Sylvain Wallez a écrit :
> Bertrand Delacretaz wrote:
>> ....In the meantime, maybe offering an embeddable version of your
>> "dynamic pipelines" thing would be a great help in getting more
>> people to use the unique things that Cocoon has to offer. But it's a
>> much smaller vision than yours ;-)
>
> Yes, but that can be the first step: define this pipeline API and the
> minimal amount of components for it to be usable (a parser, an XSLT
> and XInclude transformer and a bunch of serializers), and build on it.
> Doing it that way can also ensure this pipeline API is kept
> independent from the surrounding front-end, be it flowscript, Spring
> webflow or an ESB engine....
I like this as an initial vision for Cocoon 3.0: take a small part of
what we have that is really unique (XML processing pipelines), and
repackage it as a small POJO-based thing that people can use in
different contexts.
I've thought a bit more about your RT, and I think the single most
important thing in ensuring a future for Cocoon and the community is
** We need to play better with others **
We have some great things (Pipelines, Forms, Flow as an innovative way
of glueing java components together, Continuations) but to use them
people have to commit to Cocoon as a whole. It's a big decision, and
considering the amount of (justified) uncertainty about Java's future
as an application language, I think less people will make this decision
in the next year.
I think being able to deliver our good things in smaller embeddable
packages would make a big difference: people can then pick what they
need from Cocoon yet continue working with the tools that they're used
to.
If the overall Cocoon offering is useful to them, they might switch
completely later on, but at first they'd just use parts of Cocoon
within their existing environment, and start to love them because
they're useful to them, not because we told them to love these things
(which is what we're trying to do currently, with little success).
As a nice side effect, such a structure would *force* clean modularity
on us.
So my conclusion is: the mutation that we need is towards embeddable
POJOs, which allow our unique stuff to be reused elsewhere, in small
packages.
The dream of having the Java applications world switch to Cocoon is
over, yet we have many cool things to offer - this is an opportunity to
broaden the use of these cool things.
-Bertrand
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> I need more time to think about all this, for now here are a few
> thoughts:
>
> Le 2 déc. 05, à 18:59, Sylvain Wallez a écrit :
>
>> ...Dynamic pipelines
> ...
>> I'd like to be able to write the following in a flowscript:
>>
>> var pipeline = flow.newPipeline("non-caching");
>> pipeline.setGenerator("stream");
>> pipeline.addTransformer("xslt", "normalize.xsl");
>> if (cocoon.matchers.xpath("/foo/bar[@id = '" +
>> cocoon.session.attributes.bar_id + "']", pipeline)) {
>> handleBar(pipeline);
>> } else {
>> wrongId();
>> }
>
> IMHO, being able to use this stuff *outside* of Cocoon, without having
> to learn more than that, would make a big difference. A small facade
> with a clever class loader should make it possible to embed this
> PipelineEngine in most any java environment, not?
>
> After all these years, the really unique thing about Cocoon is still
> the XML-based processing pipelines. Being able to use this as a small
> embeddable component would add a lot of value to our offering.
Yep. And not only that: it can be a strong marketing asset. If
CocoonPipelines becomes a defacto standard for sophisticated XML
processing, it can spread in many places and bring many users. They may
not use the web front-end at first, but are more likely to get infected
than if they have to buy the whole thing in a single bundle.
>> ....Tell me your thoughts. Am I completely off-track,...
>
> Again, I need more time to think about all this but I like your ideas
> very much.
>
> Trying to play the devil's advocate, the questions that come to mind are
>
> a) Do we need this?
> If we were a company I'd ask about the return on investment: from all
> this, what are the two most important features or components that will
> bring us forward?
There are technical and non-technical answers:
- our "customer" base is shrinking: sure many people use it, but the
population is aging, and not much new users are coming in
- technically, Cocoon is reaching its limits in terms of evolution. Tons
of legacy accumulated over the years make it really hard to bring in new
things.
> b) Are we able to execute this?
> IIUC, what you're suggesting amounts to a rewrite of large parts of
> Cocoon.
I would even go as far as saying a full rewrite. Now this doesn't means
starting from scratch, as we have our knowledge, and lots of interesting
code that can be extracted and placed in a new structure.
> Problem is, it seems like very few of us are currently able to
> regularly dedicate significant amounts of time and energy to the
> development of new things here.
Yep. But this community is slowly dying anyway, so either we go to
retirement with a few old-timers keeping the product alive, or we
consider more radical changes that will rejuvenate the old-timers and
attract young people.
> Starting a big "this-new-thing-is-going-to-be-so-good" project sounds
> very risky to me at this time, unless there's a way to do it in small
> steps which each bring something to our users. Or unless someone who
> wants it is able to commit sufficient resources to it, of course...but
> we know that there has to be a community behind such an effort.
>
>> ... or do you also want to build this great new thing?...
>
> I'd love to...but I'm not sure if I have a need for that in my current
> and envisionable projects. And the realities of life won't allow me to
> spend a significant part of my time on it unfortunately.
>
> In the meantime, maybe offering an embeddable version of your "dynamic
> pipelines" thing would be a great help in getting more people to use
> the unique things that Cocoon has to offer. But it's a much smaller
> vision than yours ;-)
Yes, but that can be the first step: define this pipeline API and the
minimal amount of components for it to be usable (a parser, an XSLT and
XInclude transformer and a bunch of serializers), and build on it. Doing
it that way can also ensure this pipeline API is kept independent from
the surrounding front-end, be it flowscript, Spring webflow or an ESB
engine.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Luca Morandini <lm...@ieee.org>.
Bertrand Delacretaz wrote:
> Le 3 déc. 05, à 14:04, Luca Morandini a écrit :
>
>> Excuse me Bertrand, but I fail to see what's so special about this: I
>> did this (and an aggregator too) in ASP about an year ago (I missed
>> Cocoon very badly in that project) and I presume you can do the same
>> in Java with no need for Cocoon, can't you ?
>
> Of course you can build pipelines without Cocoon, but the idea is to be
> able to easily reuse our existing components, aggregators, transformers,
> serializers, etc.
Hmm... some of them are already packaged as indipendent Java libraries
(Batik, Xalan, etc.); moreover, it seems to me like eating the skin and
discarding the pulp of Cocoon... but to a non-Cocoon sort of a guy it
may look a sensible option.
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 3 déc. 05, à 14:04, Luca Morandini a écrit :
> Bertrand Delacretaz wrote:
>> Le 2 déc. 05, à 18:59, Sylvain Wallez a écrit :
>>> ...Dynamic pipelines
>> IMHO, being able to use this stuff *outside* of Cocoon, without
>> having to learn more than that, would make a big difference. A small
>> facade with a clever class loader should make it possible to embed
>> this PipelineEngine in most any java environment, not?
>
> Excuse me Bertrand, but I fail to see what's so special about this: I
> did this (and an aggregator too) in ASP about an year ago (I missed
> Cocoon very badly in that project) and I presume you can do the same
> in Java with no need for Cocoon, can't you ?
Of course you can build pipelines without Cocoon, but the idea is to be
able to easily reuse our existing components, aggregators,
transformers, serializers, etc.
-Bertrand
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Luca Morandini <lm...@ieee.org>.
Bertrand Delacretaz wrote:
>
> Le 2 déc. 05, à 18:59, Sylvain Wallez a écrit :
>
>> ...Dynamic pipelines
>
> IMHO, being able to use this stuff *outside* of Cocoon, without having
> to learn more than that, would make a big difference. A small facade
> with a clever class loader should make it possible to embed this
> PipelineEngine in most any java environment, not?
Excuse me Bertrand, but I fail to see what's so special about this: I
did this (and an aggregator too) in ASP about an year ago (I missed
Cocoon very badly in that project) and I presume you can do the same in
Java with no need for Cocoon, can't you ?
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Bertrand Delacretaz <bd...@apache.org>.
I need more time to think about all this, for now here are a few
thoughts:
Le 2 déc. 05, à 18:59, Sylvain Wallez a écrit :
> ...Dynamic pipelines
...
> I'd like to be able to write the following in a flowscript:
>
> var pipeline = flow.newPipeline("non-caching");
> pipeline.setGenerator("stream");
> pipeline.addTransformer("xslt", "normalize.xsl");
> if (cocoon.matchers.xpath("/foo/bar[@id = '" +
> cocoon.session.attributes.bar_id + "']", pipeline)) {
> handleBar(pipeline);
> } else {
> wrongId();
> }
IMHO, being able to use this stuff *outside* of Cocoon, without having
to learn more than that, would make a big difference. A small facade
with a clever class loader should make it possible to embed this
PipelineEngine in most any java environment, not?
After all these years, the really unique thing about Cocoon is still
the XML-based processing pipelines. Being able to use this as a small
embeddable component would add a lot of value to our offering.
> ....Tell me your thoughts. Am I completely off-track,...
Again, I need more time to think about all this but I like your ideas
very much.
Trying to play the devil's advocate, the questions that come to mind are
a) Do we need this?
If we were a company I'd ask about the return on investment: from all
this, what are the two most important features or components that will
bring us forward?
b) Are we able to execute this?
IIUC, what you're suggesting amounts to a rewrite of large parts of
Cocoon.
Problem is, it seems like very few of us are currently able to
regularly dedicate significant amounts of time and energy to the
development of new things here.
Starting a big "this-new-thing-is-going-to-be-so-good" project sounds
very risky to me at this time, unless there's a way to do it in small
steps which each bring something to our users. Or unless someone who
wants it is able to commit sufficient resources to it, of course...but
we know that there has to be a community behind such an effort.
> ... or do you also want to build this great new thing?...
I'd love to...but I'm not sure if I have a need for that in my current
and envisionable projects. And the realities of life won't allow me to
spend a significant part of my time on it unfortunately.
In the meantime, maybe offering an embeddable version of your "dynamic
pipelines" thing would be a great help in getting more people to use
the unique things that Cocoon has to offer. But it's a much smaller
vision than yours ;-)
-Bertrand
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by hepabolu <he...@gmail.com>.
Guys,
I've read the post and all of your reactions (35 at this time). Although
I cannot fathom the implications of most proposals, I'll try to
summarize what I think you (and I) generally agree on:
Cocoon in its current form needs an extreme makeover/complete overhaul
with the following keywords being the central focus:
- simplicity
- productivity
- fun/sexy
To expand on that:
Cocoon should be easy to use, in vary many different ways: easy start
for newcomers, easy to build your own application with, easy to embed in
other applications/frameworks, easy to understand.
I think productivity will automatically increase when simplicity is
increased.
Cocoon should be fun and sexy. The fun factor is definitely tied to the
simplicity and productivity factors. The easier and faster you can do
something with Cocoon, the more fun it will be to use it. The sexiness
come from being able to look at the latest developments, recognizing and
integrating the good and throwing out the "one-night stands". In short:
if Cocoon doesn't pick it up, it's not worth investigating it.
What all this means in terms of code, I have no idea, but I do know this:
- the current developer group needs to find a better balance between the
current bunch of creative friends and a regular project team. Cocoon has
become a beast because everybody could add code that was thought to be a
fun feature or solved a personal frustration. If you want a simple,
clean, lean and mean Cocoon machine, you need more of a project team
that "judges the parts by looking at the whole" and gets everyone
focused in the same direction.
- if you want Cocoon 3.0 you have to either turn Cocoon 2.2 into 3.0 or
ditch it altogether. Cocoon 3.0 will never happen when 2.2 is around.
Since there has been no release of 2.2 yet, you might want to skip that
entirely.
What this means to me is that in order to renew Cocoon, the community
should renew itself. Before building the software, build a vision and
make sure that everyone who wants to contribute knows what to do and
which rules should be followed. Adjust the way the community works. Do
we need a different organisation, more/other rules? All this only to
allow creativity to flow, but in the right direction.
Don't venture of in technical discussions about the best solution to
solve the problem, when the problem hasn't been defined properly and
been agreed on by everyone. And don't write the solution and find the
problem afterwards. We're capable of producing higher quality than that.
And of course write documentation. I've read the discussions: "you can't
write documentation about something that's not there/still changing" and
"you won't attract users when there is no documentation". To me
documentation comes in cycles too: write early, write often and
integrate the writing process in your development cycles.
Bye, Helma
Re: Stable CForms (Re: [RT][long] Cocoon 3.0: the necessary mutation)
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 10 janv. 06, à 09:59, Sylvain Wallez a écrit :
>
>> ...Let's mark CForms stable now. There are so many people using it
>> that any change has to be made backwards compatible anyway even if
>> marked unstable to avoid breaking everything...
>
> Agreed, but I think this needs a clear statement (in status.xml for
> example, so that it appears in the changes list) about which version
> Forms.js we consider stable. AFAIK it's the "v1" Forms.js.
Well, actually, vx (x > 1) will simply be deleted.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Stable CForms (Re: [RT][long] Cocoon 3.0: the necessary mutation)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 10 janv. 06, à 09:59, Sylvain Wallez a écrit :
> ...Let's mark CForms stable now. There are so many people using it
> that any change has to be made backwards compatible anyway even if
> marked unstable to avoid breaking everything...
Agreed, but I think this needs a clear statement (in status.xml for
example, so that it appears in the changes list) about which version
Forms.js we consider stable. AFAIK it's the "v1" Forms.js.
-Bertrand
Re: Stable CForms (Re: [RT][long] Cocoon 3.0: the necessary mutation)
Posted by Ralph Goers <Ra...@dslextreme.com>.
+1000
It just so happens that my boss wants to push us towards JSF and one of
the factors has been that CForms is "unstable".
Ralph
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Yeah, we were affected by this problem very often in the past. It's
>> really annoying. I really don't know why we are not able to make cforms
>> final and give the users a stable platform. But all attempts in the past
>> were rejected. Perhaps it's time to stress this again.
>>
>
>
> Let's mark CForms stable now. There are so many people using it that
> any change has to be made backwards compatible anyway even if marked
> unstable to avoid breaking everything.
>
> So putting the "stable" stamp is just accepting the de facto situation.
>
> Sylvain
>
Re: Stable CForms (Re: [RT][long] Cocoon 3.0: the necessary mutation)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Yeah, we were affected by this problem very often in the past. It's
>> really annoying. I really don't know why we are not able to make cforms
>> final and give the users a stable platform. But all attempts in the past
>> were rejected. Perhaps it's time to stress this again.
>>
>
>
> Let's mark CForms stable now. There are so many people using it that
> any change has to be made backwards compatible anyway even if marked
> unstable to avoid breaking everything.
>
> So putting the "stable" stamp is just accepting the de facto situation.
+1
/Daniel
Stable CForms (Re: [RT][long] Cocoon 3.0: the necessary mutation)
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Yeah, we were affected by this problem very often in the past. It's
> really annoying. I really don't know why we are not able to make cforms
> final and give the users a stable platform. But all attempts in the past
> were rejected. Perhaps it's time to stress this again.
>
Let's mark CForms stable now. There are so many people using it that any
change has to be made backwards compatible anyway even if marked
unstable to avoid breaking everything.
So putting the "stable" stamp is just accepting the de facto situation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
...
>Sascha-Matthias Kulawik wrote:
>
>
...
>>Another point are reliable API's. It is worse enough, that no Template System is
>>marked final
>>
The refactored JXTG should be marked stable, it is supposed to be back
compatible with the 2.1.x version. And new template development will be
called CTemplate and will use another namespace. The template block
contains some template framework apis that not are stable yet. But that
is a completely different question, that shouldn't affect anyone, all
apis in the template block (except for the JXT generator and transformer
of course) should be considered internal for the time being.
/Daniel
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Sascha-Matthias,
I really appreciate your mail - I think that's exactly what we need:
feedback from users. What do they think? etc. So many thanks. Some more
comments inline:
Sascha-Matthias Kulawik wrote:
> <snip/>
> Usual stuff, but Cocoon runs very slow in this environment, especially CForms
> and the newer JXTransformer. Tested on Intel Hardware or using Tomcat would
> solve the problem. Ive done a lot of performance optimizing but however, it
> never runs as fast as on JBoss. Some CForms Applications on BEA 6 with JDK 1.3
> are running with an evil Cocoon SVN Checkout because this is the first version
> where the Rhino stuff is working but the last where Cocoon runs on JDK 1.3.
Interesting. Do you know why it is slower on BEA?
> Another point are reliable API's. It is worse enough, that no Template System is
> marked final and even CForms is still beta. It IS worse, that you wont be able
> to run your application on the next Cocoon Version. We still can not switch some
> applications from 2.1.6 to the actual version because of changes in Cocoon.
> CForms has Version 1, 2 and 3 - where discussed on the last GetTogether in Gent
> the Version 1 becomes the final Version.
> What do you expect from your users? Throw away all stuff done before?
Yeah, we were affected by this problem very often in the past. It's
really annoying. I really don't know why we are not able to make cforms
final and give the users a stable platform. But all attempts in the past
were rejected. Perhaps it's time to stress this again.
> THats the point why stuff like JSF is much cooler in some cases then Cocoon. You
> can use many implementations (actutal SUN, Apache, Oracle) if one seems buggy,
> the API is RELIABLE and you can do updates of the implementation with small test
> efford.
Yepp, updating from one 2.1.x version to another is really a pain.
> <SNIP/>
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: CForms slower with JXTemplateGenerator
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> --- Jean-Baptiste Quenot <jb...@anyware-tech.com>
> schrieb:
>
>
>>* Sascha-Matthias Kulawik:
>>
>>
>>>Usual stuff, but Cocoon runs very slow in this
>>
>> environment,
>>
>>>especially CForms and the newer JXTransformer.
>>
>>Tested on Intel
>>
>>>Hardware or using Tomcat would solve the problem.
>>
>>Do you mean using CForms's jx-macros.xml with
>>JXTemplateGenerator?
>>I also noticed that it's much slower
>> than using
>>FormsTemplateTransformer. But Sylvain told me
>>to use the
>>JXTemplateGenerator from Cocoon 2.2 (trunk) in
>>Cocoon 2.1. Has
>>anyone tried that combination?
>
>
> I did some tests about half a year ago with the
> generator (+ macros) from the JXTemplate-block (2.2).
> After fixing some problems with the help of Daniel and
> Leszek it was as fast as (or even a bit faster) than
> the FormsTransformer.
>
> If the performance is bad in recent tests, it might be
> a problem introduced in the meantime as the macros and
> jxtemplate have been refactored and extended .
I do not recall any serious changes being made that would affect
performance.
About the combination of 2.1 with jxtg 2.2: The main problem I predict
is a different object model provided for templates (in 2.2 Request,
Response, Session and Context attributes have been extended in order to
clarify things).
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: CForms slower with JXTemplateGenerator
Posted by Reinhard Poetz <re...@yahoo.de>.
--- Jean-Baptiste Quenot <jb...@anyware-tech.com>
schrieb:
> * Sascha-Matthias Kulawik:
>
> > Usual stuff, but Cocoon runs very slow in this
> environment,
> > especially CForms and the newer JXTransformer.
> Tested on Intel
> > Hardware or using Tomcat would solve the problem.
>
> Do you mean using CForms's jx-macros.xml with
> JXTemplateGenerator?
> I also noticed that it's much slower
> than using
> FormsTemplateTransformer. But Sylvain told me
> to use the
> JXTemplateGenerator from Cocoon 2.2 (trunk) in
> Cocoon 2.1. Has
> anyone tried that combination?
I did some tests about half a year ago with the
generator (+ macros) from the JXTemplate-block (2.2).
After fixing some problems with the help of Daniel and
Leszek it was as fast as (or even a bit faster) than
the FormsTransformer.
If the performance is bad in recent tests, it might be
a problem introduced in the meantime as the macros and
jxtemplate have been refactored and extended .
--
Reinhard
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: CForms slower with JXTemplateGenerator
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
* Sascha-Matthias Kulawik:
> Usual stuff, but Cocoon runs very slow in this environment,
> especially CForms and the newer JXTransformer. Tested on Intel
> Hardware or using Tomcat would solve the problem.
Do you mean using CForms's jx-macros.xml with JXTemplateGenerator?
I also noticed that it's much slower than using
FormsTemplateTransformer. But Sylvain told me to use the
JXTemplateGenerator from Cocoon 2.2 (trunk) in Cocoon 2.1. Has
anyone tried that combination?
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sascha-Matthias Kulawik <sa...@kulawik.de>.
Carsten Ziegeler <cziegeler <at> apache.org> writes:
>
> Sylvain Wallez wrote:
> > Tell me your thoughts. Am I completely off-track, or do you also want to
> > build this great new thing?
> >
> Hmm, I don't know - I think your ideas make mostly sense (we already
> discussed some of them in the past), but for me these are technical
> details (I don't say that they are not important). But I think, we need
> a vision for 3.0 - what do we want to achieve?
>
> Now, most of the alternatives to Cocoon have one thing in common: they
> are easy too learn and you can start quickly (and most of them have the
> "start quick and fail later" problem but that's another story). Whereas
> if you want to use Cocoon, you can't start right away. There is so much
> to learn, so many different files you have to write/adjust.
>
> Why do managers love Struts or JSF? It's a "standard" but even more
> important, they have tools. Fancy tools sell your product, that's the
> bitter truth. And I have the feeling, that products, that don't have
> tools but are "just cool", will not be used anymore (it's just a feeling).
Hello Carsten, Sylvain,
I can tell you about my situation. We have developed a lot of applications based
on Cocoon, first of all we have pointed our CMS on Cocoon Technology. In the
last 2 years we started using Cocoon also for creating complex applications with
CForms. Before, we just used Cocoon as container for Authentication, Content
retrieval, aggregation, composition and all you can do with XSP.
CForms seems to be the best for us - we are having a lot of Cocoon know how,
CForms is fast to develop (in comparison with Struts) and everything could be
customized.
But we've forgotten something - and this was becomings my worst decision ever
made. The customer has a dedicated hosting environment, BEA 8.1, Apache, Oracle
and SUN JDK 1.4.2 all on Solaris / Sparc.
Usual stuff, but Cocoon runs very slow in this environment, especially CForms
and the newer JXTransformer. Tested on Intel Hardware or using Tomcat would
solve the problem. Ive done a lot of performance optimizing but however, it
never runs as fast as on JBoss. Some CForms Applications on BEA 6 with JDK 1.3
are running with an evil Cocoon SVN Checkout because this is the first version
where the Rhino stuff is working but the last where Cocoon runs on JDK 1.3.
Another point are reliable API's. It is worse enough, that no Template System is
marked final and even CForms is still beta. It IS worse, that you wont be able
to run your application on the next Cocoon Version. We still can not switch some
applications from 2.1.6 to the actual version because of changes in Cocoon.
CForms has Version 1, 2 and 3 - where discussed on the last GetTogether in Gent
the Version 1 becomes the final Version.
What do you expect from your users? Throw away all stuff done before?
THats the point why stuff like JSF is much cooler in some cases then Cocoon. You
can use many implementations (actutal SUN, Apache, Oracle) if one seems buggy,
the API is RELIABLE and you can do updates of the implementation with small test
efford. If you have some cool tools like NitroX, I think it is more pragmatic to
use JSF with a faster result then using CFOrms for that.
For me as developer I have learned that an unreliable API might be faster at the
beginning, but will kicks your ass afterwards.
I wont use any Cocoon API again without beeing sure the API is marked final and
the used Cocoon Version has no bugs in that part so I can use it in that case if
a newer Cocoon Version has changed the API.
The first sentences from Silvain are absolutely correct - it is necessary to
jump on the bandwagon and support the newest development mythologies like:
POJOs, Ajax, IoC, DI and so on.
Especially an excellent Ajax Support is very important, I think this trend will
tend even more and more Swing / Client Applications to be ported to the web.
The newest trends in J2EE are also important: POJOs, support of enterprise grade
persistence (EJB3.0) instead of no-standard-implementations, switch the Avalon
Container (sorry, dont know how far you guys are) to Spring container or another
lightweight container platform, think about a standard interfacing to get
reliable APIs, support of trails (https://trails.dev.java.net/) or a cocoon
implementation, better interaction between other enterprise J2EE stuff like
jetspeed or pluto and definitely a better test or use on weblogic, websphere and
others.
Just dont be angry about my receiveables, this are just my 2 cent after about 5
years Cocoon development.
Sascha
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.12.2005 05:54, Carsten Ziegeler wrote:
> I'm still in the "we don't need OSGi"
> camp (as some of us are here), as I still believe that it adds to much
> complexity. But as others (who I trust) believe in this and as I don't
> have time to work on this, the only way to progress is to not block
> those who have time to do something. But I come more and more to the
> conclusion that we simply should use Spring as the base framework and
> build some class loading stuff on top of it (which we already have with
> the sitemap classloaders). That would be a simple but sufficient solution.
I second this. We talk about learning less technologies and introduce
different technologies for the container and the applications - or is
anybody really considering to build an application based on OSGi while
this is much more probable for Spring?
Jörg
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
>
> Hmm, and why not having a graphical pipeline builder on top? I've
> recently seen some vendor products doing exactly that - they are not
> using Cocoon underneath, but have a similar product and really nice tools.
>
Just forgot to add: the nice drag and drop tool to develop something is
not the key here. The added functionality, like debugging, setting
breakpoints in the pipeline, reporting etc. make you very productive.
Now if you compare our sitemap with BPEL then you see that noone really
writes BPEL by hand - it's a nightmare without a tool - in this respect
our sitemap language is much better :) But the tools provide you
enhanced functionality.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> Tools are actually a way to hide complexity.
Yupp.
> What if the tool you need
> is a plain Java IDE with a JavaScript plugin because all you have is a
> pipeline API and Flowscript/Javaflow?
>
Hmm, and why not having a graphical pipeline builder on top? I've
recently seen some vendor products doing exactly that - they are not
using Cocoon underneath, but have a similar product and really nice tools.
> Sorry, but saying that a build tool is the solution to our problems is
> burying you head in the sand, as it's just trying to automate the
> management of complexity.
>
It's not the solution for all of our problems, but it helps in being
productive. First time Cocoon users always ask "Ok, I've downloaded
Cocoon and now what? How do I manage my project?" And then later on "How
do I update my Cocoon version?" And so on. Automatic build management is
imho a must for every project (it enables continuous integration etc.)
> And IMO we don't even need that. As was Gianugo said later, the whole
> blocks stuff, if you think about it, is just about adding an additional
> level of complexity in the hope to hide the current one. Just like the
> sophisticated build tool, actually.
>
Hehe, good try :) Now, actually, this is one of the points where I
currently disagree. But I'm very happy to be profen wrong. Adding
another level of complexity in the hope to hide the current one, seems a
little bit strange to me whereas we currently don't have a build
solution at all - I mean a solution for building projects that use
Cocoon. But anyways, let's see what the future brings :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Tell me your thoughts. Am I completely off-track, or do you also want to
>> build this great new thing?
>>
> Hmm, I don't know - I think your ideas make mostly sense (we already
> discussed some of them in the past), but for me these are technical
> details (I don't say that they are not important). But I think, we need
> a vision for 3.0 - what do we want to achieve?
>
Here's what I want to achieve:
- simplicity: use less XML files, have a small number of versatile but
understandable components
- productivity: sensible defaults, fast try/fail cycles
- scripted J2EE: JDK 1.6 will ship with Rhino, meaning a lot of products
will offer JS as a scripting language. Cocoon is the first one.
- integration: integrating something in Cocoon is easy, but the other
way around is a mess. A smaller set of loosely coupled features can
allow people to come to Cocoon to grab what they need (e.g. a pipeline
engine), and hopefully later be interested by its other features
- considering the architectural paradigm changes that comes with Ajax
apps, that place the controller at the center of the picture and change
the nature of the request/response model by moving away from full page
reloads.
> Now, most of the alternatives to Cocoon have one thing in common: they
> are easy too learn and you can start quickly (and most of them have the
> "start quick and fail later" problem but that's another story). Whereas
> if you want to use Cocoon, you can't start right away. There is so much
> to learn, so many different files you have to write/adjust.
>
> Why do managers love Struts or JSF? It's a "standard" but even more
> important, they have tools. Fancy tools sell your product, that's the
> bitter truth. And I have the feeling, that products, that don't have
> tools but are "just cool", will not be used anymore (it's just a feeling).
>
Tools are actually a way to hide complexity. What if the tool you need
is a plain Java IDE with a JavaScript plugin because all you have is a
pipeline API and Flowscript/Javaflow?
> I think from a technological point of view, Cocoon is still at the top,
> we can easily support ajax, we could integrate Spring or spring flow if
> required etc. But I think, developing with Cocoon needs to be more
> productive than it is today.
>
> Just an example, CForms is a great framework, it offers everything you
> need - but providing a simple form for editing a bean requires several
> different files to be created.
>
Yup. Totally agree.
> In the end it comes down to the following two things: we need a good
> documentation and it must be productive to develop with Cocoon.
>
Sure, but can we be productive enough with today's Cocoon?
> I'm not a believer of all these "too-much-magic" frameworks or
> generating stuff. So I think using Cocoon should be simpler and we need
> tools. Why don't we have tools? For example, we don't have a sitemap
> editor, we even don't have a simple tool that can validate a sitemap or
> an xconf etc. Not to mention that developing with Cocoon currently
> requires to define your own build system.
>
> For some of our problems, we already have answers, being it using Maven,
> implementing real blocks, adding this new feature here and there. And we
> are very good in agreeing on these things, but we are not that good in
> actually doing them :(
>
> So, yes, I think we need some radical changes for 3.0 - but I fail to
> see what these should be. There are two things clear for me: developing
> with Cocoon must get easier, and we'll get this with Maven - and we need
> much better docs. (Of course, the docs have heavily improved in the last
> months but many things are simply not documented at all yet).
>
Sorry, but saying that a build tool is the solution to our problems is
burying you head in the sand, as it's just trying to automate the
management of complexity.
> And to give some more meat to discuss (or rant about) as I will be
> offline for the next ten days: I'm still in the "we don't need OSGi"
> camp (as some of us are here), as I still believe that it adds to much
> complexity. But as others (who I trust) believe in this and as I don't
> have time to work on this, the only way to progress is to not block
> those who have time to do something. But I come more and more to the
> conclusion that we simply should use Spring as the base framework and
> build some class loading stuff on top of it (which we already have with
> the sitemap classloaders). That would be a simple but sufficient solution.
>
And IMO we don't even need that. As was Gianugo said later, the whole
blocks stuff, if you think about it, is just about adding an additional
level of complexity in the hope to hide the current one. Just like the
sophisticated build tool, actually.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Tell me your thoughts. Am I completely off-track, or do you also want to
> build this great new thing?
>
Hmm, I don't know - I think your ideas make mostly sense (we already
discussed some of them in the past), but for me these are technical
details (I don't say that they are not important). But I think, we need
a vision for 3.0 - what do we want to achieve?
Now, most of the alternatives to Cocoon have one thing in common: they
are easy too learn and you can start quickly (and most of them have the
"start quick and fail later" problem but that's another story). Whereas
if you want to use Cocoon, you can't start right away. There is so much
to learn, so many different files you have to write/adjust.
Why do managers love Struts or JSF? It's a "standard" but even more
important, they have tools. Fancy tools sell your product, that's the
bitter truth. And I have the feeling, that products, that don't have
tools but are "just cool", will not be used anymore (it's just a feeling).
I think from a technological point of view, Cocoon is still at the top,
we can easily support ajax, we could integrate Spring or spring flow if
required etc. But I think, developing with Cocoon needs to be more
productive than it is today.
Just an example, CForms is a great framework, it offers everything you
need - but providing a simple form for editing a bean requires several
different files to be created.
In the end it comes down to the following two things: we need a good
documentation and it must be productive to develop with Cocoon.
I'm not a believer of all these "too-much-magic" frameworks or
generating stuff. So I think using Cocoon should be simpler and we need
tools. Why don't we have tools? For example, we don't have a sitemap
editor, we even don't have a simple tool that can validate a sitemap or
an xconf etc. Not to mention that developing with Cocoon currently
requires to define your own build system.
For some of our problems, we already have answers, being it using Maven,
implementing real blocks, adding this new feature here and there. And we
are very good in agreeing on these things, but we are not that good in
actually doing them :(
So, yes, I think we need some radical changes for 3.0 - but I fail to
see what these should be. There are two things clear for me: developing
with Cocoon must get easier, and we'll get this with Maven - and we need
much better docs. (Of course, the docs have heavily improved in the last
months but many things are simply not documented at all yet).
And to give some more meat to discuss (or rant about) as I will be
offline for the next ten days: I'm still in the "we don't need OSGi"
camp (as some of us are here), as I still believe that it adds to much
complexity. But as others (who I trust) believe in this and as I don't
have time to work on this, the only way to progress is to not block
those who have time to do something. But I come more and more to the
conclusion that we simply should use Spring as the base framework and
build some class loading stuff on top of it (which we already have with
the sitemap classloaders). That would be a simple but sufficient solution.
For new (portal) projects, I think it makes sense to use Cocoon as the
portal framework, but to use JSF etc to build the portals. Sad, but
true. Developing with Cocoon is not productive, so we need to change
this :) Ok, I'll now go offline for some time and come back when the
waves (hopefully) have cleared...
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Michael Wechner <mi...@wyona.com>.
Sylvain Wallez wrote:
>
> All this to say that if we want Cocoon to have a bright future, it
> must go through a mutation.
agreed
>
> Tell me your thoughts. Am I completely off-track,
I cannot judge the technical implications you wrote about above, but
I think I have the same feeling and I don't think at all that you are
off the track.
I also think that Cocoon would have the capability of representing the
good side of both "worlds" (rapid prototyping as is possible with "Ruby"
and on the other hand what J2EE land has to offer).
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
Re: [RT] The next shiny thing?
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> How can you be so certain that we would getting less complicated if we
> started from scratch? It might be complicated because it does
> something complicated. As long as you don't understand the internals
> you cannot really know, can you?
I do. And you don't know how many hours I spent trying to understand why
this or that was written and what could break when I found how to fix a bug.
And IMNSHO there are simpler ways to do the same thing.
> Managing complexity is much about finding the right concepts and work
> really hard to get the right interfaces. The people who built Cocoon
> from the begining spent a lot of time and effort in getting the apis
> right. Since then we have made the apis bulky whithout doing that much
> refactoring to keep things simple.
I agree. And one of the biggest problem with the current code base is
that we don't know where the contracts are, meaning that changing things
is awfully difficult because we have to maintain overall compatibility.
A revamped code base can be organized from the start to give solutions
to this problem:
- clearly identify and document public contracts.
- distinguish internal and public classes (Java's private keyword isn't
enough here)
- design public classes for subclassing or make them final.
That way we know where the compatibility effort must go.
We can also learn a lot of Eclipse in this regard, as they are
particularly cautious about APIs. They have a lot of documents (e.g. [1]
and [2]) and some automated tools to ensure API stability.
> What we need to do is to refactor and rearchitecture Cocoon so that we
> get rid of bulk that isn't used anymore. And to adapt for things that
> we would like to add.
>
> Every time I try to discuss apis people get bored. So I have not much
> faith in that the current community would end up with something better
> and more elegant than what we have if we started from scratch. Neither
> do I see that anyone would be prepared to spend the time and effort
> that it would take.
This is IMO because doing this job afterwards is really boring. Making
it a project rule means you have to consider it from the start.
> But please, suprise me.
I hope we will :-)
<snip/>
> It is so easy to ditch other peoples work, isn't it?
It's even easier to ditch your own code. I will happily trash thousands
of lines I wrote for Cocoon. But they will not be lost, because I
learned from them (and I hope others as well), and because this code
will continue to live in a different way.
Sylvain
[1]
http://www.eclipse.org/webtools/development/arch_and_design/pq-apis-20041115.ppt
[2] http://eclipse.org/eclipse/development/java-api-evolution.html
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The next shiny thing?
Posted by David Crossley <cr...@apache.org>.
Gianugo Rabellino wrote:
> David Crossley wrote:
> > Gianugo Rabellino wrote:
> > > Daniel Fagerstrom wrote:
> > >
> > > > It is so easy to ditch other peoples work, isn't it?
> > >
> > > Oh, come on Daniel, you're taking this personally.
> >
> > I reckon that Daniel has hit on many important issues
> > related to community-building. If people are not careful
> > then we are going to lose many of our current developers.
>
> Which is what, more or less, is happening today, albeit at a slow
> pace.
Yep, it is a current and ongoing issue.
> Just look at the commits or try to find common patterns in the
> evolutionary discussion: what you will see is a really small bunch of
> people talking and coding, whereas this community used to have long
> threads and fast paces.
That is part of the problem. Too much discussion,
too fast a pace, and not enough implementation.
I reckon that these are general OSS problems.
> Daniel is right, when you talk APIs people get
> bored: you could look at it from an ivory tower and label that as
> childish attitude and , or you can do something to change that and
> address the real issue which, to me, is lack of people that are
> confident enough to talk about internals because, basically, they
> don't feel they belong. C3 is, to me, a step forward in that
> direction.
I am talking about a higher level of consolidation,
a level where many people can be involved.
> > > I strongly respect
> > > and admire what you've been doing to push Cocoon 2.2 forward, but you
> > > also have to realize how hard it would be for you to carry the burden
> > > of being the main responsible for such a core part of Cocoon without a
> > > real committment from the community, which I'm not really seeing at
> > > the moment. You should realize how the biggest feeling floating around
> > > the Cocoon community is that we want to do something to make Cocoon
> > > fly and soar high in the skies, instead than strive to survive its own
> > > complexity.
> >
> > Cocoon would have already been soaring if we had
> > polished the system and documented as we went.
>
> Symptoms, again. Then why on earth the system isn't polished? Lazy
> butts or nearly-to-impossible work?
IMO because people rush off to the next new thing
and do not consolidate their work. To make matters
worse developers generally do not document their stuff
or provide sufficient Samples. So those left behind have
no way to follow, or assist, or build upon and refine.
> Cocoon 2.2 is cleaner, but it
> won't refrain people from telling me how their project could benefit
> from some Cocoon features, but since the beast is so complex, they're
> just looking elsewhere or implement in-house Cocoon clones. Cocoon,
> today, is a terrific tool if you have complex needs (simplifying hard
> stuff) but it falls short to address the medium to simple stuff, which
> is where the real beef, community wise, is.
>
> > We would have retained many of the new people
> > that we had attracted. I get the feeling that our
> > discussions are going to frighten the hell out of
> > our existing community. We have not yet solidified
> > our current offering and now are racing on to the
> > next new thing. So why should they trust us to not
> > repeat that behaviour. We are in danger of being seen
> > as a research project.
>
> I'm surprised to hear from you what to me looks like sweeping problems
> under the rug because they'd scare people away: ...
Nah, i am not against moving forward. I am helping
to identify a core problem with our community.
It is an ongoing sickness that will not change with
any technical leaps.
The alarm bell that i rang above is that users were
told that we intended to consolidate with 2.2, so now
they must be wondering if we are all talk and perhaps
not able to ever consolidate.
> ... to me, what's really
> going on is a bunch of children shouting that the Emperor is naked,
> what I'd actually expect from the community I want to belong to is
> understanding how we are able to identify what the real issues are,
> and address them accordingly.
There are various issues, both technical and community.
-David
> Mind you, having some strong business interests in terms of existing
> projects with Cocoon 2, I shouldn't really be this much shouting about
> moving on in possibly incompatible ways: if I've been repeating from
> months now that we need a 3.0 (remember AC EU?), this is because I
> think that without a clear step forward, all we can do are small steps
> solving our self-induced problems while the world is clearly moving to
> different solutions and scenarios. The Cocoon community has never been
> a (late) follower as we risk of being now: if shaking the tree helps
> regaining momentum, then I'm all for an open discussion about it.
>
> Ciao,
> --
> Gianugo Rabellino
> Pro-netics s.r.l. - http://www.pro-netics.com
> Orixo, the XML business alliance: http://www.orixo.com
> (blogging at http://www.rabellino.it/blog/)
Re: 2.2 vs 3.0, or 2.2 then 3.0?
Posted by Sylvain Wallez <sy...@apache.org>.
Upayavira wrote:
<snip/>
> So, no-one is offending anyone else by suggesting 3.0. Anyone shouting
> about 3.0 also likely needs 2.2 for their businesses to continue to
> function in the time until someone actually implements 3.0, and probably
> for some significant time after.
>
Exactly. And for the old-timers that remember the 1.x -> 2.0 transition,
it didn't happened overnight. Development of 2.0 started around January
2000 (I wasn't there), and several 1.x revision were released until 2.0
final came out in november 2001.
We're about to enter the exact same process.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: 2.2 vs 3.0, or 2.2 then 3.0?
Posted by Sylvain Wallez <sy...@apache.org>.
Upayavira wrote:
> On another point - if 3.0 starts as an embedable pipeline engine, surely
> we can embed that into our existing 2.2 systems? Thus having hybrid
> systems working until such a point as we have migrated everything across
> to the new architecture.
>
Very good point! That can be a way to ensure progressive migration to
the new features and give early feedback on them.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: 2.2 vs 3.0, or 2.2 then 3.0?
Posted by Upayavira <uv...@odoko.co.uk>.
Berin Loritsch wrote:
> Upayavira wrote:
>
>> So, 2.2 = important, and 3.0 = important. Both.
>>
>> We need to avoid discussions, implications, emotions, etc that suggest
>> otherwise.
>>
>>
>
> Right. If any of that has gone on, I'm sure its unintentional. If
> memory serves me correctly, Cocoon 2 was written as a branch, and
> Maintenance was happening on Cocoon 1 for a while.
>
> There did come a time when work stopped on Cocoon 1, but that was after
> Cocoon 2 was released.
>
> Basically, new/exciting stuff should go in Cocoon 3, and touch ups to
> Cocoon 2 until Cocoon 3 is ready for prime time.
Yes, generally I agree. But even that makes it sound that the whole 2.x
branch is now in "maintenance mode" which is far from the case. 2.2
should bring those of us using Cocoon significant advantages, and can
continue to be an exciting place to operate for some time to come.
2.2->3.0 is _very_ different to 2.1->2.2. We can expect 2.1 to die
relatively quickly, as apps can be ported with a manageable amount of
effort. That will likely not be the case for 2.2->3.0, so therefore we
can best consider 2.2 and 3.0 to be different products, rather than
versions of the same thing. 2.2 will have a life, much like httpd 1.3
lived long after the release of 2.0.
2.2 needs exciting stuff too. At the same time, adding stax processing
to it might though be a push too far.
On another point - if 3.0 starts as an embedable pipeline engine, surely
we can embed that into our existing 2.2 systems? Thus having hybrid
systems working until such a point as we have migrated everything across
to the new architecture.
Regards, Upayavira
Re: 2.2 vs 3.0, or 2.2 then 3.0?
Posted by Upayavira <uv...@odoko.co.uk>.
hepabolu wrote:
> Berin Loritsch wrote:
>
>> Upayavira wrote:
>>
>>> So, 2.2 = important, and 3.0 = important. Both.
>>>
>>> We need to avoid discussions, implications, emotions, etc that suggest
>>> otherwise.
>>>
>>>
>>
>> Right. If any of that has gone on, I'm sure its unintentional. If
>> memory serves me correctly, Cocoon 2 was written as a branch, and
>> Maintenance was happening on Cocoon 1 for a while.
>>
>> There did come a time when work stopped on Cocoon 1, but that was
>> after Cocoon 2 was released.
>>
>> Basically, new/exciting stuff should go in Cocoon 3, and touch ups to
>> Cocoon 2 until Cocoon 3 is ready for prime time.
>
>
> Fine, but times might be much more hectic now with less people having
> less time to contribute to either version. There is still the 2.1 branch
> to maintain as well.
> So I think that the time of maintaining 2 versions (actually 3) should
> be as short as possible and that apart from the current Maven and blocks
> nothing new should be added to 2.2, however exciting that may be.
Actually, I tend to disagree. As has been pointed out, this is open
source, so an exciting new 3.0 project could easily bring fresh blood,
thus not depleting 2.x at all.
> More important I think is not only defining the "vision of Cocoon 3.0"
> as precisely as possible (so all jumping up and down now, know exactly
> where to jump in), and coming up with a roadmap, but also to try and
> define/write conversion tools (however simple) almost from the beginning
> that can ease the transition from 2.1/2.2 to 3.0. If the tedious 60% can
> be done automatically, it shows the current user base they are not
> abandoned.
Yup.
> AND PLEASE TAKE THE DOCUMENTATION INTO ACCOUNT! However rudimentary,
> write something, give an example and make sure the docs stay up-to-date.
And with Daisy in place, this should be much easier.
Regards, Upayavira
Re: 2.2 vs 3.0, or 2.2 then 3.0?
Posted by Berin Loritsch <bl...@d-haven.org>.
hepabolu wrote:
> More important I think is not only defining the "vision of Cocoon 3.0"
> as precisely as possible (so all jumping up and down now, know exactly
> where to jump in), and coming up with a roadmap, but also to try and
> define/write conversion tools (however simple) almost from the
> beginning that can ease the transition from 2.1/2.2 to 3.0. If the
> tedious 60% can be done automatically, it shows the current user base
> they are not abandoned.
>
> AND PLEASE TAKE THE DOCUMENTATION INTO ACCOUNT! However rudimentary,
> write something, give an example and make sure the docs stay up-to-date.
I agree. I've done my part with 2.0/2.2 documentation. I've done my
part with Avalon documentation.
I'd like to point out that there are a couple levels of documentation:
1) Unit Tests
2) Formal Docs
Now, I think it is reasonable to have the average developer to do Unit
Test documentation. IOW, the unit tests are your first example of how
something is used. Formal docs require some skills that many developers
don't have--esp. if English is their second language. It's one thing to
understand how something works, it is quite another to describe it to
someone else. It becomes even harder when you throw an unfamiliar
language into the mix.
It would be very helpful if we could all work together, those of us who
are good at documentation and those of us who are good at developing
solutions.
Re: 2.2 vs 3.0, or 2.2 then 3.0?
Posted by hepabolu <he...@gmail.com>.
Berin Loritsch wrote:
> Upayavira wrote:
>
>> So, 2.2 = important, and 3.0 = important. Both.
>>
>> We need to avoid discussions, implications, emotions, etc that suggest
>> otherwise.
>>
>>
>
> Right. If any of that has gone on, I'm sure its unintentional. If
> memory serves me correctly, Cocoon 2 was written as a branch, and
> Maintenance was happening on Cocoon 1 for a while.
>
> There did come a time when work stopped on Cocoon 1, but that was after
> Cocoon 2 was released.
>
> Basically, new/exciting stuff should go in Cocoon 3, and touch ups to
> Cocoon 2 until Cocoon 3 is ready for prime time.
Fine, but times might be much more hectic now with less people having
less time to contribute to either version. There is still the 2.1 branch
to maintain as well.
So I think that the time of maintaining 2 versions (actually 3) should
be as short as possible and that apart from the current Maven and blocks
nothing new should be added to 2.2, however exciting that may be.
More important I think is not only defining the "vision of Cocoon 3.0"
as precisely as possible (so all jumping up and down now, know exactly
where to jump in), and coming up with a roadmap, but also to try and
define/write conversion tools (however simple) almost from the beginning
that can ease the transition from 2.1/2.2 to 3.0. If the tedious 60% can
be done automatically, it shows the current user base they are not
abandoned.
AND PLEASE TAKE THE DOCUMENTATION INTO ACCOUNT! However rudimentary,
write something, give an example and make sure the docs stay up-to-date.
Just my 0.02€
Bye, Helma
Re: 2.2 vs 3.0, or 2.2 then 3.0?
Posted by Berin Loritsch <bl...@d-haven.org>.
Upayavira wrote:
>So, 2.2 = important, and 3.0 = important. Both.
>
>We need to avoid discussions, implications, emotions, etc that suggest
>otherwise.
>
>
Right. If any of that has gone on, I'm sure its unintentional. If
memory serves me correctly, Cocoon 2 was written as a branch, and
Maintenance was happening on Cocoon 1 for a while.
There did come a time when work stopped on Cocoon 1, but that was after
Cocoon 2 was released.
Basically, new/exciting stuff should go in Cocoon 3, and touch ups to
Cocoon 2 until Cocoon 3 is ready for prime time.
RE: 2.2 vs 3.0, or 2.2 then 3.0?
Posted by Matthew Langham <ml...@s-und-n.de>.
Upayavira nails it IMO.
>
> So, 2.2 = important, and 3.0 = important. Both.
>
> We need to avoid discussions, implications, emotions, etc
> that suggest otherwise.
>
> We need to give the message to our existing users that their
> code will be supported for a long time, that it is still safe
> to continue using 2.1/2.2. After all, we will all ourselves
> have code using it for a long time, much like some of us
> probably have code running that still uses Cocoon 1.X.
>
+1
Remember: Without Users there will be no need for either a version 3 or 2.2!
Matthew
2.2 vs 3.0, or 2.2 then 3.0?
Posted by Upayavira <uv...@odoko.co.uk>.
Gianugo Rabellino wrote:
<snip type="big"/>
> Mind you, having some strong business interests in terms of existing
> projects with Cocoon 2, I shouldn't really be this much shouting about
> moving on in possibly incompatible ways: if I've been repeating from
> months now that we need a 3.0 (remember AC EU?), this is because I
> think that without a clear step forward, all we can do are small steps
> solving our self-induced problems while the world is clearly moving to
> different solutions and scenarios. The Cocoon community has never been
> a (late) follower as we risk of being now: if shaking the tree helps
> regaining momentum, then I'm all for an open discussion about it.
I think what Gianugo says here is really important.
Yes, I think we do need to be thinking about 3.0 in a radical new way,
we do have too many self-imposed problems to solve in our current
generation.
But at the same time, the majority if not all of us have investments in
2.x based technologies. If someone handed us a complete 3.0
implementation today, it'd surely take us all some time before we'd
switch, whether in recoding our apps, or retraining our staff, or whatever.
So we need to work out how 2.2 and 3.0 play together. We need to get 2.2
out. I for one need it. But 2.2 is going to make life _much_ easier for
people who are _already_ using Cocoon. We need something that is going
to bring in significant new blood.
So, 2.2 = important, and 3.0 = important. Both.
We need to avoid discussions, implications, emotions, etc that suggest
otherwise.
We need to give the message to our existing users that their code will
be supported for a long time, that it is still safe to continue using
2.1/2.2. After all, we will all ourselves have code using it for a long
time, much like some of us probably have code running that still uses
Cocoon 1.X.
Any project will need to be 'revisioned' at times. Take the delightful
'Visual Basic', VB6 is incompatible with VB7. Sometimes it just needs to
be done. That didn't stop people using VB6, at least not immediately
(unfortunately for them ;-) ).
So, no-one is offending anyone else by suggesting 3.0. Anyone shouting
about 3.0 also likely needs 2.2 for their businesses to continue to
function in the time until someone actually implements 3.0, and probably
for some significant time after.
Let's get 2.2 out, and let's continue to mull on the nature of 3.0, and
thank you to Sylvain for restarting the discussion.
Regards, Upayavira
Re: [RT] The next shiny thing?
Posted by Gianugo Rabellino <gi...@gmail.com>.
On 12/5/05, David Crossley <cr...@apache.org> wrote:
> Gianugo Rabellino wrote:
> > Daniel Fagerstrom wrote:
> >
> > > It is so easy to ditch other peoples work, isn't it?
> >
> > Oh, come on Daniel, you're taking this personally.
>
> I reckon that Daniel has hit on many important issues
> related to community-building. If people are not careful
> then we are going to lose many of our current developers.
Which is what, more or less, is happening today, albeit at a slow
pace. Just look at the commits or try to find common patterns in the
evolutionary discussion: what you will see is a really small bunch of
people talking and coding, whereas this community used to have long
threads and fast paces. Daniel is right, when you talk APIs people get
bored: you could look at it from an ivory tower and label that as
childish attitude and , or you can do something to change that and
address the real issue which, to me, is lack of people that are
confident enough to talk about internals because, basically, they
don't feel they belong. C3 is, to me, a step forward in that
direction.
> > I strongly respect
> > and admire what you've been doing to push Cocoon 2.2 forward, but you
> > also have to realize how hard it would be for you to carry the burden
> > of being the main responsible for such a core part of Cocoon without a
> > real committment from the community, which I'm not really seeing at
> > the moment. You should realize how the biggest feeling floating around
> > the Cocoon community is that we want to do something to make Cocoon
> > fly and soar high in the skies, instead than strive to survive its own
> > complexity.
>
> Cocoon would have already been soaring if we had
> polished the system and documented as we went.
Symptoms, again. Then why on earth the system isn't polished? Lazy
butts or nearly-to-impossible work? Cocoon 2.2 is cleaner, but it
won't refrain people from telling me how their project could benefit
from some Cocoon features, but since the beast is so complex, they're
just looking elsewhere or implement in-house Cocoon clones. Cocoon,
today, is a terrific tool if you have complex needs (simplifying hard
stuff) but it falls short to address the medium to simple stuff, which
is where the real beef, community wise, is.
> We would have retained many of the new people
> that we had attracted. I get the feeling that our
> discussions are going to frighten the hell out of
> our existing community. We have not yet solidified
> our current offering and now are racing on to the
> next new thing. So why should they trust us to not
> repeat that behaviour. We are in danger of being seen
> as a research project.
I'm surprised to hear from you what to me looks like sweeping problems
under the rug because they'd scare people away: to me, what's really
going on is a bunch of children shouting that the Emperor is naked,
what I'd actually expect from the community I want to belong to is
understanding how we are able to identify what the real issues are,
and address them accordingly.
Mind you, having some strong business interests in terms of existing
projects with Cocoon 2, I shouldn't really be this much shouting about
moving on in possibly incompatible ways: if I've been repeating from
months now that we need a 3.0 (remember AC EU?), this is because I
think that without a clear step forward, all we can do are small steps
solving our self-induced problems while the world is clearly moving to
different solutions and scenarios. The Cocoon community has never been
a (late) follower as we risk of being now: if shaking the tree helps
regaining momentum, then I'm all for an open discussion about it.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: [RT] The next shiny thing?
Posted by David Crossley <cr...@apache.org>.
Gianugo Rabellino wrote:
> Daniel Fagerstrom wrote:
>
> > It is so easy to ditch other peoples work, isn't it?
>
> Oh, come on Daniel, you're taking this personally.
I reckon that Daniel has hit on many important issues
related to community-building. If people are not careful
then we are going to lose many of our current developers.
> I strongly respect
> and admire what you've been doing to push Cocoon 2.2 forward, but you
> also have to realize how hard it would be for you to carry the burden
> of being the main responsible for such a core part of Cocoon without a
> real committment from the community, which I'm not really seeing at
> the moment. You should realize how the biggest feeling floating around
> the Cocoon community is that we want to do something to make Cocoon
> fly and soar high in the skies, instead than strive to survive its own
> complexity.
Cocoon would have already been soaring if we had
polished the system and documented as we went.
We could simply cruise higher.
We would have retained many of the new people
that we had attracted. I get the feeling that our
discussions are going to frighten the hell out of
our existing community. We have not yet solidified
our current offering and now are racing on to the
next new thing. So why should they trust us to not
repeat that behaviour. We are in danger of being seen
as a research project.
I too hope that we are evolving not revolving.
Thanks Daniel for expressing your concerns.
-David
Re: [RT] The next shiny thing?
Posted by Jorg Heymans <jh...@domek.be>.
Gianugo Rabellino wrote:
<snip/>
>
> Well, I think I do know at least something that blocks will buy us.
> But again, what I'm questioning is whether the problems that blocks
> solve are self-inflicted pains (love that wording, Berin) or real
> problems that have a direct impact on users. So far what I'm seeing is
> the need to learn yet another tool (Maven2) to manage block's
> complexity: does that *really* go in the direction of helping users?
> I'm not that sure anymore.
>
sure it does :-)
We need to be able to release our blocks independent of the core. Being
able to produce a snapshot of a block and make it *instantly* available
to all users without even doing an official release is extremely
valuable to our end users.
Example 1 : 2.1.8 was delayed for one week because we thought the jsf
block had files in it with a non-compatible license (which turned out
not to be an issue in the end)
Example 2: since maven 2.0 was released, issue [1] is blocking our
ability to use archetypes. I spoke to Jason (vanzyl) again about this
yesterday evening, and he offered to do a quick fix. One hour later i
had a new snapshot of the archetype plugin with a workaround. There was
no previous big discussion on how to best implement it, no new release,
no code freeze, no vote - nada.
Yes we can manage this all ourselves, but maven makes it soooo much
easier. And ofcourse we will hide the perceived complexity for our users
through tooling.
Regards
Jorg
[1] http://jira.codehaus.org/browse/ARCHETYPE-1
Re: [RT] The next shiny thing?
Posted by Gianugo Rabellino <gi...@gmail.com>.
On 12/4/05, Daniel Fagerstrom <da...@nada.kth.se> wrote:
> Gianugo Rabellino wrote:
>
> >Daniel,
> >
> >thank you for taking the time to write this. I understand your
> >frustration, since the behaviour you're describing in your email has
> >clearly been a recurring pattern lately on dev@cocoon. However, I'd
> >like to ask you to try and see beyond what happened,
> >
> Sorry, while I'm not juging people, I base my trust on what they will
> deliver in the future on what they have delivered in the past, rather
> than on promisses that everything will be different this time.
Are you sure you're being fair to this community? Just look back and
see what people has brought you before many of us even faced up: this
is what has been delivered in the past, and it's no peanuts to me.
Sure enough, if you consider the past year or so, there has been a lot
more talk then just code, but I don't think it's fair to look at what
we're currently discussing with a snicker, thinking that it's "just
talk as usual". This team did deliver lots of good stuff, then, while
enjoying some success, lost somehow motivation. What you don't seem to
understand is how, even among this closed group of highly committed
people, who nearly bet the house upon Cocoon, there is a clear will to
move on and, while at it, have fun again.
> >why we have been able to build Cocoon 2 but we seem not to be able to
> >go any further: the answer to that, to me, clearly denotes the need
> >for some kind of (soft?) revolution, e.g. Cocoon 3.
> >
> We are having a soft revolution right now, I ask you and the rest of the
> community for some persistance instead of start running in still another
> direction.
I'm sorry, Daniel, but what I'm seeing doesn't look interesting enough
to (re)attract a large user base over here. Of course what I'm
expecting from 2.2 is a set of very nice improvements and some
solutions to a few problems, but I don't see how blocks would take the
real complexity out of Cocoon. Or better: some complexity will be
hidden, but still using Cocoon will mean committing to it and to the
way it does things, which is increasingly of little interest to the
vast majority of web developers out there. No fun, no gain.
And, to answer your specific question, yes, we can stick a few more
months watching you guys doing a terrific work in rationalising
internals, but even if you were doing the best work in the world, once
finished you'll risk to hear us saying "hmmmm... so what?" again and
again.
> >My reading of what's happening over here is that we've got to a point
> >where Cocoon internals have become way too complicated, way to
> >difficult to understand and way too difficult to interact with: I
> >think we'd need no more than one hand to count the number of (active)
> >people over here who could comfortably talk about the pipeline engine,
> >the sitemap interpreter, the caching sytem and all that.
> >
> How can you be so certain that we would getting less complicated if we
> started from scratch? It might be complicated because it does something
> complicated. As long as you don't understand the internals you cannot
> really know, can you?
Sure, I might not grasp completely what's going on under the hood
today. But my gut feeling is that Cocoon is overengineered in many
parts of it and not correctly layered on some other parts. I have a
few opinions about it, but they are way off topic in this discussion.
> Managing complexity is much about finding the right concepts and work
> really hard to get the right interfaces. The people who built Cocoon
> from the begining spent a lot of time and effort in getting the apis
> right. Since then we have made the apis bulky whithout doing that much
> refactoring to keep things simple.
>
> What we need to do is to refactor and rearchitecture Cocoon so that we
> get rid of bulk that isn't used anymore. And to adapt for things that we
> would like to add.
I have the feeling that we're saying the same thing. What you don't
seem to grasp is why there is a camp that feels this is actually
Cocoon 3, something different from what we have now, something that
can be - and here is where we differ - achived best with revolution
rather than with evolution. Now, I think there is a major
misunderstanding in what "start from scratch" really means: to me, it
means getting back to the drawing board, trying to reuse what can be
reused but being ready to ditch unnecessary load just because it could
be incompatible with the vision.
> Every time I try to discuss apis people get bored. So I have not much
> faith in that the current community would end up with something better
> and more elegant than what we have if we started from scratch. Neither
> do I see that anyone would be prepared to spend the time and effort that
> it would take.
>
> But please, suprise me.
Oh, definitely hope so! :-) The good news for you is that so far such
attempts had a tendency to sudden failure, so I guess we'll see in a
very short time if this could be the right occasion to move things
forward or if we'll wake up to the 2.2 reality instead than pursuing a
3.0 vision. Won't take long, methinks.
> >I don't buy it. It might look like that, and I understand why you read
> >it as that, but to me the truth is that there is little to no interest
> >in providing a small relief to a huge headache (I still have to
> >understand why real blocks would rock, apart from being ubercool
> >technically wise)
> >
> I'm sorry that Stefano and I and others have failed to communicate to
> you why blocks rocks. I guess I just can say that they do rock and that
> they solve a lot of our current problems.
Well, I think I do know at least something that blocks will buy us.
But again, what I'm questioning is whether the problems that blocks
solve are self-inflicted pains (love that wording, Berin) or real
problems that have a direct impact on users. So far what I'm seeing is
the need to learn yet another tool (Maven2) to manage block's
complexity: does that *really* go in the direction of helping users?
I'm not that sure anymore.
> >So true. But you have to live with it and ask yourself why that new
> >and shiny stuff that got people so excited wasn't that sexy after all
> >to overcome the inertia of actually making it work. Either we're a
> >bunch of creative people with no technical skill (and no, I don't
> >believe that), or there is just *way* too much inertia to make
> >anything happen with the current codebase. I clearly buy the latter.
> >
> >
> I think we are a bunch of CTO types that where really good programmers
> in the past but have been used to that someone else does the programming
> and that it is enough for us to talk ;)
You know, this wink actually makes a lot of sense. It's definitely
true that in these past five years many of us (myself included)
switched to the "executive" field. It could possibly be that this
Cocoon 3 discussion is also an excuse to fire up that IDE again, but
do remind that there are no CTOs in OSS: I'd rather talk about
motivators and catalysts. Fair enough, we have to show some code to
see the final proof: we'll see if these old farts can come up with
something nice. :-)
> >Community based Open Source shines when there is a (small) number of
> >technically strong people that provide a codebase where even medium to
> >low range guys can interact with: this happened in the very first days
> >of Cocoon 2, when everyone and his dog provided additional components
> >so fast that we soon filled up the available space, so what's next?
> >
> >
> Real blocks.
Nah. Real blocks don't seem to solve real issues, to me. Love to be
proven wrong, of course: the idea of ditching stuff really doesn't
have a strong appeal to me, unless it's a last resort alternative.
> >Are we looking for more de-facto one man shows with code spikes that
> >inevitably lead to frustration and make people disaffect or leave? I'd
> >much rather jump on what are the challenges we foresee and try to
> >catch them, even if that means ditching most of what we've got so far.
> >
> >
> It is so easy to ditch other peoples work, isn't it?
Oh, come on Daniel, you're taking this personally. I strongly respect
and admire what you've been doing to push Cocoon 2.2 forward, but you
also have to realize how hard it would be for you to carry the burden
of being the main responsible for such a core part of Cocoon without a
real committment from the community, which I'm not really seeing at
the moment. You should realize how the biggest feeling floating around
the Cocoon community is that we want to do something to make Cocoon
fly and soar high in the skies, instead than strive to survive its own
complexity.
> >This is not so true. Sylvain's discussion is catalyzing an important
> >message there: there is really no reason to bother about integrating
> >with existing stuff, because this would just make things worse.
> >Rewrites are risky, that's true, but anything that takes more than
> >three years to become real is doomed to fail (this -
> >http://tinyurl.com/86ke5 - isn't the earliest example I could find,
> >but it shows you we were talking blocks back in 2002). When are we
> >going to realize it?
> >
> >
> I started to work on blocks in April this year,
> http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=111411975927551&w=2,
> since then I and others have implemented most of what was discussed in
> 2002 and have a good plan for implementing the rest.
Again, you shouldn't take these discussion as a personal attack to
your work as in you not being fast enough in completing the journey to
real blocks. What happened here is that people started to realize how
real blocks aren't the real solution to what our audience wants, no
matter how big and great they might be.
> >Gosh, Daniel, an outstanding agenda. I'll be watching closely what
> >seems to be a notable list of accomplishments, hoping to help out as
> >well (whatever happens to 3.0, I intend to provide strong and
> >long-standing support for 2.x as well, so every step further is most
> >welcome). But I'm also most interested in seeing things moving forward
> >from a community point of view, stopping the drift of people looking
> >elsewhere (there must be a reason for that, right?).
> >
> >
> I guess there are many reasons for people looking elsewhere. IMO, some
> important reasons is that Cocoon is incoherent and that it is hard to
> develop it further. That we never release so that you never get the
> pleasure of being able to use your new code and innovations in new
> projects or seeing other people use it.
OK, that's a great way of pointing up symptoms, and we basically all
agree on them. Can we move on to diagnosing the reasons for that and
finding a cure? Can you try and prove us wrong when we say that the
current mix of community and code base doesn't seem likely to bring
innovation back to Cocoon-land?
> >>take some minutes and read why Joel Spolesky thinks that rewriting
> >>software from scratch is the:
> >>
> >> *single worst strategic mistake* that any software company can make
> >>
> >>http://www.joelonsoftware.com/articles/fog0000000069.html.
> >>
> >Two notes here:
> >
> >1. Joel is talking about companies. Open Source is *much* different.
> >
> It is, but it is so different wrt rewriting from scratch?
Yup. Because Open Source as a whole can afford it. Because Open Source
as a whole doesn't have a real budget or a mission when it comes to a
project that counts as a drop in the ocean. Because the Open Source
communities swarm around cool technologies and, just like locusts,
tend to abandon fields where the technical stuff is basically over.
That's the flip side of the coin, of course, we all know the major
pluses that come from this very peculiar environment, and I think we
all want to leverage them.
And, then again, clean slate doesn't necessarily mean rewriting from
scratch: what we're trying to achieve is a drastic semplification on
the way Cocoon is built today, while following the usual goal of world
domination through XML pipelines and continuation-based webapp
development.
> >2. I don't read Sylvain's proposal as a "let's dump everything". What
> >I see is a different and fresh approach to real issues, and a solution
> >that goes towards maximum reuse of what we've got so far, ditching as
> >much as we can of the infrastructure burden we've been carrying on for
> >ages.
> >
> >
> I agree with Sylvain about much of the suggested improvements, but not
> about starting from scratch.
I think here Sylvain might shed some more light on what he does mean
exactly with starting from scratch: I can only reiterate that what I
mean with that is starting with a clear mind, ready to abandon
unneeded stuff if it make sense, while trying to retain as much as
possible of what we've got now.
> > maybe the problem is elsewhere, e.g. the current core being too
> >heavyweight and the user visible part being way to hard to understand?
> >
> Yes, it needs refactoring.
Let's then see what we mean with refactoring: it could well be that
what I consider a rewrite in large chunks is just refactoring to you.
I have the feeling that if we take personal feelings like ditching
other's people work off from this discussion, we have a good chance to
get very far. Just keep the ball rolling.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: [RT] The next shiny thing?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Gianugo Rabellino wrote:
>Daniel,
>
>thank you for taking the time to write this. I understand your
>frustration, since the behaviour you're describing in your email has
>clearly been a recurring pattern lately on dev@cocoon. However, I'd
>like to ask you to try and see beyond what happened,
>
Sorry, while I'm not juging people, I base my trust on what they will
deliver in the future on what they have delivered in the past, rather
than on promisses that everything will be different this time.
> asking yourself
>why we have been able to build Cocoon 2 but we seem not to be able to
>go any further: the answer to that, to me, clearly denotes the need
>for some kind of (soft?) revolution, e.g. Cocoon 3.
>
>
We are having a soft revolution right now, I ask you and the rest of the
community for some persistance instead of start running in still another
direction.
>My reading of what's happening over here is that we've got to a point
>where Cocoon internals have become way too complicated, way to
>difficult to understand and way too difficult to interact with: I
>think we'd need no more than one hand to count the number of (active)
>people over here who could comfortably talk about the pipeline engine,
>the sitemap interpreter, the caching sytem and all that.
>
How can you be so certain that we would getting less complicated if we
started from scratch? It might be complicated because it does something
complicated. As long as you don't understand the internals you cannot
really know, can you?
Managing complexity is much about finding the right concepts and work
really hard to get the right interfaces. The people who built Cocoon
from the begining spent a lot of time and effort in getting the apis
right. Since then we have made the apis bulky whithout doing that much
refactoring to keep things simple.
What we need to do is to refactor and rearchitecture Cocoon so that we
get rid of bulk that isn't used anymore. And to adapt for things that we
would like to add.
Every time I try to discuss apis people get bored. So I have not much
faith in that the current community would end up with something better
and more elegant than what we have if we started from scratch. Neither
do I see that anyone would be prepared to spend the time and effort that
it would take.
But please, suprise me.
> We could go
>on for ages and try to find a temporary solution (no matter how
>architecturally sound) hoping that people like you get interested into
>the framework in order to better separate stuff, but to me it's pretty
>clear that we wouldn't be going anywhere far. So:
>
>
>>The main problem with our community, IMO, is the lack of focus and
>>persistance. We have so many great ideas, but as large parts of the
>>community always are running towards the next shiny thing and have very
>>little interest in polishing the design, contracts and implementations.
>>
>>
>I don't buy it. It might look like that, and I understand why you read
>it as that, but to me the truth is that there is little to no interest
>in providing a small relief to a huge headache (I still have to
>understand why real blocks would rock, apart from being ubercool
>technically wise)
>
I'm sorry that Stefano and I and others have failed to communicate to
you why blocks rocks. I guess I just can say that they do rock and that
they solve a lot of our current problems.
> when the amount of code to understand before you can
>actually "fix" something is so massive that it makes your head spin.
>And this is just talking about fixing existing stuff, when it's pretty
>clear that we need to move way forward if we want to stay ahead of the
>flock (something we *always* did in the past and we're failing to
>achieve at this point).
>
>
>>After having been around for a couple of years, I start to recognize our
>>development cycle: First a new sexy idea is suggested, and we all jumps
>>up and down shouting out our excitement. Then we might start to discuss
>>design and implementation, and most people lose interest or maybe drop
>>by and complains about that the discussion have become technical and
>>that it bire them stiff. After that some people might even implement it.
>>And as it often takes a lot of work to design and implement cool stuff
>>it takes a while. And when it finally start to get somewhere, people are
>>not even remotely interested anymore because there is something new and
>>shiny to jump up and down and shout about.
>>
>>
>
>So true. But you have to live with it and ask yourself why that new
>and shiny stuff that got people so excited wasn't that sexy after all
>to overcome the inertia of actually making it work. Either we're a
>bunch of creative people with no technical skill (and no, I don't
>believe that), or there is just *way* too much inertia to make
>anything happen with the current codebase. I clearly buy the latter.
>
>
I think we are a bunch of CTO types that where really good programmers
in the past but have been used to that someone else does the programming
and that it is enough for us to talk ;)
>Community based Open Source shines when there is a (small) number of
>technically strong people that provide a codebase where even medium to
>low range guys can interact with: this happened in the very first days
>of Cocoon 2, when everyone and his dog provided additional components
>so fast that we soon filled up the available space, so what's next?
>
>
Real blocks.
>Are we looking for more de-facto one man shows with code spikes that
>inevitably lead to frustration and make people disaffect or leave? I'd
>much rather jump on what are the challenges we foresee and try to
>catch them, even if that means ditching most of what we've got so far.
>
>
It is so easy to ditch other peoples work, isn't it?
>>Instead of focus on our core ideas and functionalities, and ensure that
>>we have real high quality implementations of them, we just add still
>>another prototype implementation of something new whithout bothering
>>about how it integrates with the rest of what we have.
>>
>>
>This is not so true. Sylvain's discussion is catalyzing an important
>message there: there is really no reason to bother about integrating
>with existing stuff, because this would just make things worse.
>Rewrites are risky, that's true, but anything that takes more than
>three years to become real is doomed to fail (this -
>http://tinyurl.com/86ke5 - isn't the earliest example I could find,
>but it shows you we were talking blocks back in 2002). When are we
>going to realize it?
>
>
I started to work on blocks in April this year,
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=111411975927551&w=2,
since then I and others have implemented most of what was discussed in
2002 and have a good plan for implementing the rest.
What happened was that I decided that I wanted blocks and started to
incrementally and persistently work towards getting them.
>>So I'm sorry, I will not jump up and down and shout together with the
>>rest of you this time. I will persist and continue with the work in
>>trunk on what I think is important:
>>
>>* finishing blocks
>>* make the m2 build system work and become the only one
>>* binary releases
>>* strengthen the contracts
>>* improve the quality
>>* split up Cocoon in smaller parts
>>* deprecate things that not are or not should be used anymore
>>* strive for coherence
>>* refactoring and rearchitecturing mercelesly
>>* 2.2 during Q1
>>
>>This work will continue to be evolutionary and incremental. And when we
>>have the block system and have cleaned the contracts and the messy
>>implementation of the core, it will be easy and safe to experiment with
>>new great ideas. And we are getting rather close to this point, we just
>>need to finish what we have started. And for the messines we solve that
>>with refactoring.
>>
>>
>Gosh, Daniel, an outstanding agenda. I'll be watching closely what
>seems to be a notable list of accomplishments, hoping to help out as
>well (whatever happens to 3.0, I intend to provide strong and
>long-standing support for 2.x as well, so every step further is most
>welcome). But I'm also most interested in seeing things moving forward
>from a community point of view, stopping the drift of people looking
>elsewhere (there must be a reason for that, right?).
>
>
I guess there are many reasons for people looking elsewhere. IMO, some
important reasons is that Cocoon is incoherent and that it is hard to
develop it further. That we never release so that you never get the
pleasure of being able to use your new code and innovations in new
projects or seeing other people use it.
My focus the last year or so have been on attacking these problems.
>>quite risky to try to rewrite everything from scratch, although I have
>>felt the urge myself countless time while struggling with the messy
>>internals. But before you go ahead and rewrite everything from scratch,
>>take some minutes and read why Joel Spolesky thinks that rewriting
>>software from scratch is the:
>>
>> *single worst strategic mistake* that any software company can make
>>
>>http://www.joelonsoftware.com/articles/fog0000000069.html.
>>
>>
>
>Two notes here:
>
>1. Joel is talking about companies. Open Source is *much* different.
>
>
It is, but it is so different wrt rewriting from scratch?
>2. I don't read Sylvain's proposal as a "let's dump everything". What
>I see is a different and fresh approach to real issues, and a solution
>that goes towards maximum reuse of what we've got so far, ditching as
>much as we can of the infrastructure burden we've been carrying on for
>ages.
>
>
I agree with Sylvain about much of the suggested improvements, but not
about starting from scratch.
>>For the actual functionality that Sylvain proposed I think much of it is
>>great and I have argued for things similar to some of them earlier. And
>>they can be added in an incremental way.
>>
>>
>Here is where we basically disagree. I have this feeling that, unless
>a major revamp, there is a very slim chance for Cocoon to progress
>incrementally. I thought OSGi would have helped, with modularization
>and the like, but as you can see, this is clearly has not been the
>case:
>
Please show some patience or better take part in it yourself, we are
getting there.
> maybe the problem is elsewhere, e.g. the current core being too
>heavyweight and the user visible part being way to hard to understand?
>
>
Yes, it needs refactoring.
>These are my major gripes at the moment, and while I still do believe
>that the steep learning curve of Cocoon pays off big time, I've come
>to think lately that we could actually do something to make it better.
>
>
Most definitively.
>>Leaving our core offering and rewriting everything from scratch means
>>community and product suicide, don't do it.
>>
>>
>
>Again, I don't feel this is rewriting from scratch. And while I see
>your point, I can clearly a stagnation and starvation risk ahead if we
>don't shift gears and move on. How would you risk manage that?
>
>
I risk manage it by committing my own work in what I believe in and by
trying to convince other people that it is worthwhile to work on the
same stuff. I also risk manage by avoid forking and start from scratch,
which have killed a lot of NG work previously.
The most important part of my risk management is by prioritizing and
focus on the single most important thing until it is good enough.
/Daniel
Re: [RT] The next shiny thing?
Posted by Gianugo Rabellino <gi...@gmail.com>.
Daniel,
thank you for taking the time to write this. I understand your
frustration, since the behaviour you're describing in your email has
clearly been a recurring pattern lately on dev@cocoon. However, I'd
like to ask you to try and see beyond what happened, asking yourself
why we have been able to build Cocoon 2 but we seem not to be able to
go any further: the answer to that, to me, clearly denotes the need
for some kind of (soft?) revolution, e.g. Cocoon 3.
My reading of what's happening over here is that we've got to a point
where Cocoon internals have become way too complicated, way to
difficult to understand and way too difficult to interact with: I
think we'd need no more than one hand to count the number of (active)
people over here who could comfortably talk about the pipeline engine,
the sitemap interpreter, the caching sytem and all that. We could go
on for ages and try to find a temporary solution (no matter how
architecturally sound) hoping that people like you get interested into
the framework in order to better separate stuff, but to me it's pretty
clear that we wouldn't be going anywhere far. So:
> The main problem with our community, IMO, is the lack of focus and
> persistance. We have so many great ideas, but as large parts of the
> community always are running towards the next shiny thing and have very
> little interest in polishing the design, contracts and implementations.
I don't buy it. It might look like that, and I understand why you read
it as that, but to me the truth is that there is little to no interest
in providing a small relief to a huge headache (I still have to
understand why real blocks would rock, apart from being ubercool
technically wise) when the amount of code to understand before you can
actually "fix" something is so massive that it makes your head spin.
And this is just talking about fixing existing stuff, when it's pretty
clear that we need to move way forward if we want to stay ahead of the
flock (something we *always* did in the past and we're failing to
achieve at this point).
> After having been around for a couple of years, I start to recognize our
> development cycle: First a new sexy idea is suggested, and we all jumps
> up and down shouting out our excitement. Then we might start to discuss
> design and implementation, and most people lose interest or maybe drop
> by and complains about that the discussion have become technical and
> that it bire them stiff. After that some people might even implement it.
> And as it often takes a lot of work to design and implement cool stuff
> it takes a while. And when it finally start to get somewhere, people are
> not even remotely interested anymore because there is something new and
> shiny to jump up and down and shout about.
So true. But you have to live with it and ask yourself why that new
and shiny stuff that got people so excited wasn't that sexy after all
to overcome the inertia of actually making it work. Either we're a
bunch of creative people with no technical skill (and no, I don't
believe that), or there is just *way* too much inertia to make
anything happen with the current codebase. I clearly buy the latter.
Community based Open Source shines when there is a (small) number of
technically strong people that provide a codebase where even medium to
low range guys can interact with: this happened in the very first days
of Cocoon 2, when everyone and his dog provided additional components
so fast that we soon filled up the available space, so what's next?
Are we looking for more de-facto one man shows with code spikes that
inevitably lead to frustration and make people disaffect or leave? I'd
much rather jump on what are the challenges we foresee and try to
catch them, even if that means ditching most of what we've got so far.
> Instead of focus on our core ideas and functionalities, and ensure that
> we have real high quality implementations of them, we just add still
> another prototype implementation of something new whithout bothering
> about how it integrates with the rest of what we have.
This is not so true. Sylvain's discussion is catalyzing an important
message there: there is really no reason to bother about integrating
with existing stuff, because this would just make things worse.
Rewrites are risky, that's true, but anything that takes more than
three years to become real is doomed to fail (this -
http://tinyurl.com/86ke5 - isn't the earliest example I could find,
but it shows you we were talking blocks back in 2002). When are we
going to realize it?
> So I'm sorry, I will not jump up and down and shout together with the
> rest of you this time. I will persist and continue with the work in
> trunk on what I think is important:
>
> * finishing blocks
> * make the m2 build system work and become the only one
> * binary releases
> * strengthen the contracts
> * improve the quality
> * split up Cocoon in smaller parts
> * deprecate things that not are or not should be used anymore
> * strive for coherence
> * refactoring and rearchitecturing mercelesly
> * 2.2 during Q1
>
> This work will continue to be evolutionary and incremental. And when we
> have the block system and have cleaned the contracts and the messy
> implementation of the core, it will be easy and safe to experiment with
> new great ideas. And we are getting rather close to this point, we just
> need to finish what we have started. And for the messines we solve that
> with refactoring.
Gosh, Daniel, an outstanding agenda. I'll be watching closely what
seems to be a notable list of accomplishments, hoping to help out as
well (whatever happens to 3.0, I intend to provide strong and
long-standing support for 2.x as well, so every step further is most
welcome). But I'm also most interested in seeing things moving forward
from a community point of view, stopping the drift of people looking
elsewhere (there must be a reason for that, right?).
> quite risky to try to rewrite everything from scratch, although I have
> felt the urge myself countless time while struggling with the messy
> internals. But before you go ahead and rewrite everything from scratch,
> take some minutes and read why Joel Spolesky thinks that rewriting
> software from scratch is the:
>
> *single worst strategic mistake* that any software company can make
>
> http://www.joelonsoftware.com/articles/fog0000000069.html.
Two notes here:
1. Joel is talking about companies. Open Source is *much* different.
2. I don't read Sylvain's proposal as a "let's dump everything". What
I see is a different and fresh approach to real issues, and a solution
that goes towards maximum reuse of what we've got so far, ditching as
much as we can of the infrastructure burden we've been carrying on for
ages.
> For the actual functionality that Sylvain proposed I think much of it is
> great and I have argued for things similar to some of them earlier. And
> they can be added in an incremental way.
Here is where we basically disagree. I have this feeling that, unless
a major revamp, there is a very slim chance for Cocoon to progress
incrementally. I thought OSGi would have helped, with modularization
and the like, but as you can see, this is clearly has not been the
case: maybe the problem is elsewhere, e.g. the current core being too
heavyweight and the user visible part being way to hard to understand?
These are my major gripes at the moment, and while I still do believe
that the steep learning curve of Cocoon pays off big time, I've come
to think lately that we could actually do something to make it better.
> Leaving our core offering and rewriting everything from scratch means
> community and product suicide, don't do it.
Again, I don't feel this is rewriting from scratch. And while I see
your point, I can clearly a stagnation and starvation risk ahead if we
don't shift gears and move on. How would you risk manage that?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: [RT] The next shiny thing?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.12.2005 17:00, Sylvain Wallez wrote:
>> Start a whiteboard prototype if you feel like it, but to me it seem
>> quite risky to try to rewrite everything from scratch, although I have
>> felt the urge myself countless time while struggling with the messy
>> internals. But before you go ahead and rewrite everything from
>> scratch, take some minutes and read why Joel Spolesky thinks that
>> rewriting software from scratch is the:
>>
>> *single worst strategic mistake* that any software company can make
>>
>> http://www.joelonsoftware.com/articles/fog0000000069.html.
>
>
> Although I most often find Joel Spolsky's writings very enlightning, I
> always disagreed with that one. And to understand why, consider what is
> your main browser and what mail software you used to write this. The
> headers say "User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)".
IMO Joel mixes two different things in his post: parts of code and a
complete code base of any software. His samples with string function and
the "two page function" can probably be refactored without any problem
and he is absolutely right about not just throwing it away. But it might
be very different for complete code bases. How many of these "bug fixes"
in the code base are for fixing obsolete things (e.g. Netscape's way of
rendering HTML following the standards not that well)? And also what's
the effort of getting such a code base refactored in comparison to its
rewriting - including the maintenance phase, fixing of bugs should be
much easier than before.
Now what about Cocoon? Is Cocoon a 500.000 LOC beast which can not be
refactored or maintained? Or is Cocoon more or less a collection of many
components? IMO it is the latter and we should follow Marc's proposal of
separating these components into layers. The effort should not be that
high to this in an incremental way instead of starting from scratch.
Jörg
Re: [RT] The next shiny thing?
Posted by Ralph Goers <Ra...@dslextreme.com>.
Peter Hunsberger wrote:
>
>I think it makes some sense to start talking about what a 3.0 might
>look like. Two main reason for that:
>
>First, it is good to always have a long term architectural direction
>in front of you. It is one of the ways to help keep the community
>focused on what they are doing now and where they want to go in thhe
>future.
>
>Second, it helps truly indicate that the 2.1 branch is really moving
>into maintenance mode.
>
>
>
>
Well, in principal I would agree with you except for two things.
1. 2.1 will move into maintenance mode only when a 2.2 is released.
Talking about 3.0 won't make that happen.
2. This community has had a terrible problem moving forward over the
last 2 years. While I generally agree that the items mentioned for 3.0
are a good thing, my fear as that folks will start jumping on those and
never finish polishing up a 2.2 release.
Re: [RT] The next shiny thing?
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2005-12-05 at 17:15 +0100, Sylvain Wallez wrote:
> Peter Hunsberger wrote:
>
> <snip/>
>
> > Perhaps an area on the Wiki to discuss straw man features and
> > requirements for a 3.0 release would be a good thing?
>
> See http://cocoon.zones.apache.org/daisy/test/g1/792.html (BTW, how do
> we create a new book in Daisy?)
Just create a new document of type 'Book Definition', it will then
appear along the available books to publish
(at /daisy/books/definitions)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] The next shiny thing?
Posted by Berin Loritsch <bl...@d-haven.org>.
Daniel Fagerstrom wrote:
> Berin Loritsch wrote:
>
>>> I will continue to be proud of our brand, our product and our
>>> community. And I will continue the work on *Cocoon* towards the
>>> future in an evolutionary way, so that those who have put their
>>> trust in us have a reasonable migration path to follow.
>>
>>
>> I've put a souple years into Cocoon, and I'm proud of the work that
>> I've done. I like the *concepts* behind Cocoon. The problem is that
>> I lack the patience to wait for evolution to take place--how long has
>> it been that real blocks are not a reality in Cocoon? I could
>> understand if it were just six months and you have to have some time
>> to make it happen.
>
>
> You know Berin, we have blocks. Go and read
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113335919919804&w=2.
> It says something interesting about this community that no one have
> responded to that message yet. While a thread about marketing and
> branding absorbs all the community energy (again).
:) Yes I know we have a certain implimentation of blocks that require
compiling against the core.
>
> Is Cocoon all about talk and hype? Is design and programming, and god
> forbid refactoring and testing, something old fashioned that we better
> stop worrying about?
Oh I agree that design, programming, refactoring, and testing are all
extremely important. Any attempt to do a redesign *must* have these
things working if it is to have any hope to succeed. I just believe
that we have gotten to a point where retrofitting these things is going
to take more time and energy than it will to establish them at the
inception of any new efforts.
>>
>> My friends, the comment of Ruby on Rails and simplicity has hit our
>> ecosystem. Prepare for an ice age, adapt or die. Slow adaptation
>> isn't going to cut it. Users have different expectations of their
>> frameworks now.
>
> I take this painfully slow evolutionary pace to mean that we are
> unable to adapt quickly enough. That's a real problem. Esp. when I
> don't have a clear picture of how blocks is even going to help me.
>
> Wow! isn't marketing talk fun.
Yes it is. But don't forget to see the substance behind it. The
reality is that the world around us has changed, and ignoring that fact
is just as unhealthy as doing a complete redesign every release.
> Still I fail to see a common coherent vision for this revolution
> besides that current Cocoon is messy. Sure I have seen that Sylvain
> have collected some ideas that we have discussed on the list for a
> while. Much of it that great stuff, but is it something that can't be
> achieved by refactoring Cocoon? And are they so great so that we
> should spread ourselves even thinner instead of focus on getting 2.2
> out of the door?
Right, and we do need to solidify the vision. I think the point where
we are is still trying to see if there is enough community support to do
a redesign. Nevertheless, we do need a common vision for Cocoon,
whether that is 2.2, 2.3, 3.0, or X. That way we can be sure that we
are evolving the right direction.
>>> We should focus on our core offerning and getting the parts of it
>>> reusable outside Cocoon and of high quality, following the path
>>> outlined by Marc.
>>
>>
>> Enjoy that process. There is a lot of pain involved with doing
>> restructurings of Cocoon. As much as I like Cocoon, I honestly
>> believe that the effort to bring order out of chaos is going to be
>> much higher than the effort to build a new system. That's my two cents.
>
> IMO the most important step towards getting an uppwards spiral again
> is by regaining our and our communities faith in Cocoon, by keeping
> our promisses and do a 2.2 release. Instead of running like lemmlings
> towards the next shiny thing.
I don't think anyone has suggested that we abandon 2.2. Yes, we need to
finish 2.2. We need to manage the TODO list for 2.2.
> I know about the pain of restructuring Cocoon as I'm have worked with
> core related stuff for along time. And getting some proof of concept
> code working might not be that hard. But I think that you severly
> underestimate the amount of work it will take to get a production
> quality system shipping. Not to talk about getting the trust in the
> new product when we anounce: "trust us, this time is different, this
> time we will behave responsible"
That's why I have always advocated the release early and often mantra.
I think we should institute a monthly early access release, so that we
can get the feedback we need at each stage. I would advocate that
whether the community goes evolutionary, revolutionary, or some hybrid.
Re: [RT] The next shiny thing?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Berin Loritsch wrote:
> Daniel Fagerstrom wrote:
>
>> To me:
>>
>> * throwing away the collected work of the community
>> * building something rather different
>> * throwing away a strong brand
>> * leave all the users who has put a trust in us behind
>>
>> seem like a rather strange way of "saving" Cocoon.
>
> It seemed like a rather strange way of saving Apple as well, but look
> what happened. Now I agree about the point on "throwing away a strong
> brand", because the focus of any revolution here is to clarify and
> crystalize how to use Cocoon efficiently. Now, the point of "leave
> all the users who has put a trust in us behind" is a bit of hyperbole
> IMO. This community successfully made that transition once before.
And failed a number of times since then.
Anyway, we have "rules for revolutionaries" and so on, go ahead if you
like it. I will continue the evolutionary path and it seem like others
will as well.
>> I will continue to be proud of our brand, our product and our
>> community. And I will continue the work on *Cocoon* towards the
>> future in an evolutionary way, so that those who have put their trust
>> in us have a reasonable migration path to follow.
>
> I've put a souple years into Cocoon, and I'm proud of the work that
> I've done. I like the *concepts* behind Cocoon. The problem is that
> I lack the patience to wait for evolution to take place--how long has
> it been that real blocks are not a reality in Cocoon? I could
> understand if it were just six months and you have to have some time
> to make it happen.
You know Berin, we have blocks. Go and read
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113335919919804&w=2. It
says something interesting about this community that no one have
responded to that message yet. While a thread about marketing and
branding absorbs all the community energy (again).
Is Cocoon all about talk and hype? Is design and programming, and god
forbid refactoring and testing, something old fashioned that we better
stop worrying about?
> I take this painfully slow evolutionary pace to mean that we are
> unable to adapt quickly enough. That's a real problem. Esp. when I
> don't have a clear picture of how blocks is even going to help me.
>
> My friends, the comment of Ruby on Rails and simplicity has hit our
> ecosystem. Prepare for an ice age, adapt or die. Slow adaptation
> isn't going to cut it. Users have different expectations of their
> frameworks now.
Wow! isn't marketing talk fun.
Still I fail to see a common coherent vision for this revolution besides
that current Cocoon is messy. Sure I have seen that Sylvain have
collected some ideas that we have discussed on the list for a while.
Much of it that great stuff, but is it something that can't be achieved
by refactoring Cocoon? And are they so great so that we should spread
ourselves even thinner instead of focus on getting 2.2 out of the door?
>> IMO the most important step towards getting an uppwards spiral again
>> is by regaining our and our communities faith in Cocoon, by keeping
>> our promisses and do a 2.2 release. Instead of running like lemmlings
>> towards the next shiny thing.
>>
>> We should focus on our core offerning and getting the parts of it
>> reusable outside Cocoon and of high quality, following the path
>> outlined by Marc.
>
> Enjoy that process. There is a lot of pain involved with doing
> restructurings of Cocoon. As much as I like Cocoon, I honestly
> believe that the effort to bring order out of chaos is going to be
> much higher than the effort to build a new system. That's my two cents.
I know about the pain of restructuring Cocoon as I'm have worked with
core related stuff for along time. And getting some proof of concept
code working might not be that hard. But I think that you severly
underestimate the amount of work it will take to get a production
quality system shipping. Not to talk about getting the trust in the new
product when we anounce: "trust us, this time is different, this time we
will behave responsible"
>> For you attention seekers out there, OSGi based blocks will draw a
>> lot of attention towards Cocoon, and it is innovation, not immitation.
>>
>> /Daniel
>
>
> :) Honestly, too little, too late. Just how much attention has OSGi
> received over the years? It's been around at least as long as Avalon,
> but Avalon received much more attention (albeit negative attention).
> It has been living quietly behind the scenes now for a long time.
OSGi draw enough attention to attract Eclipse. And as it takes a niche
that many projects find really important it starting to get a lot of
attention. Having a pluggin system seem to be the best known mean to
handle great complexity. And because of that many projects have build
own plugin system. Inspired by Eclipse many of them are now starting to
look at OSGi.
The Felix project have taken off lately. Eclipse have restarted its
Equinox project that is entirely dedicated to OSGi and seem to be rather
active. Eclipse 3.2 have OSGi bundle development support. Directory is
moving towards OSGi, Jonas is supposed to have OSGi support and Geronimo
is discussing getting it. There is a number of OSGi talcs on ApacheCon.
I believe that OSGi will be the next hype.
OSGi seem to take the important niche that Avalon could have had if the
Avalon community have had more focus, persistence and responsibility.
/Daniel
Re: [RT] The next shiny thing?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Romano Trampus wrote:
>Sorry, I read "spots" of this list and somebody could have written the
>same:
>
>I think the cocoon package is too big. I would prefer a core and a lot of
>plugins, not in the same distribution. I think the cocoon package is great
>but confusing. With plugins you have not to care that anything must have the
>same maturity level. And if I need a plugin I have only to download that,
>just as I do that with eclipse.
>
>
That exactly is the point with the block architecture, that will be part
of 2.2. In the next step the blocks will be OSGi bundles exactly as the
Eclipse pluggins, and they will be deployable within Eclipse as any
other pluggin, this will make a whole new level of tool support for
Cocoon possible.
/Daniel
RE: [RT] The next shiny thing?
Posted by Romano Trampus <tr...@univ.trieste.it>.
Sorry, I read "spots" of this list and somebody could have written the
same:
I think the cocoon package is too big. I would prefer a core and a lot of
plugins, not in the same distribution. I think the cocoon package is great
but confusing. With plugins you have not to care that anything must have the
same maturity level. And if I need a plugin I have only to download that,
just as I do that with eclipse.
bye
romano
-----Original Message-----
From: Berin Loritsch [mailto:bloritsch@d-haven.org]
Sent: martedì 6 dicembre 2005 14.44
To: dev@cocoon.apache.org
Subject: Re: [RT] The next shiny thing?
Daniel Fagerstrom wrote:
> To me:
>
> * throwing away the collected work of the community
> * building something rather different
> * throwing away a strong brand
> * leave all the users who has put a trust in us behind
>
> seem like a rather strange way of "saving" Cocoon.
It seemed like a rather strange way of saving Apple as well, but look
what happened. Now I agree about the point on "throwing away a strong
brand", because the focus of any revolution here is to clarify and
crystalize how to use Cocoon efficiently. Now, the point of "leave all
the users who has put a trust in us behind" is a bit of hyperbole IMO.
This community successfully made that transition once before.
>
> I will continue to be proud of our brand, our product and our
> community. And I will continue the work on *Cocoon* towards the future
> in an evolutionary way, so that those who have put their trust in us
> have a reasonable migration path to follow.
I've put a souple years into Cocoon, and I'm proud of the work that I've
done. I like the *concepts* behind Cocoon. The problem is that I lack
the patience to wait for evolution to take place--how long has it been
that real blocks are not a reality in Cocoon? I could understand if it
were just six months and you have to have some time to make it happen.
I take this painfully slow evolutionary pace to mean that we are unable
to adapt quickly enough. That's a real problem. Esp. when I don't have
a clear picture of how blocks is even going to help me.
My friends, the comment of Ruby on Rails and simplicity has hit our
ecosystem. Prepare for an ice age, adapt or die. Slow adaptation isn't
going to cut it. Users have different expectations of their frameworks now.
>
> IMO the most important step towards getting an uppwards spiral again
> is by regaining our and our communities faith in Cocoon, by keeping
> our promisses and do a 2.2 release. Instead of running like lemmlings
> towards the next shiny thing.
>
> We should focus on our core offerning and getting the parts of it
> reusable outside Cocoon and of high quality, following the path
> outlined by Marc.
Enjoy that process. There is a lot of pain involved with doing
restructurings of Cocoon. As much as I like Cocoon, I honestly believe
that the effort to bring order out of chaos is going to be much higher
than the effort to build a new system. That's my two cents.
>
> For you attention seekers out there, OSGi based blocks will draw a lot
> of attention towards Cocoon, and it is innovation, not immitation.
>
> /Daniel
:) Honestly, too little, too late. Just how much attention has OSGi
received over the years? It's been around at least as long as Avalon,
but Avalon received much more attention (albeit negative attention). It
has been living quietly behind the scenes now for a long time.
Re: [RT] The next shiny thing?
Posted by Berin Loritsch <bl...@d-haven.org>.
Daniel Fagerstrom wrote:
> To me:
>
> * throwing away the collected work of the community
> * building something rather different
> * throwing away a strong brand
> * leave all the users who has put a trust in us behind
>
> seem like a rather strange way of "saving" Cocoon.
It seemed like a rather strange way of saving Apple as well, but look
what happened. Now I agree about the point on "throwing away a strong
brand", because the focus of any revolution here is to clarify and
crystalize how to use Cocoon efficiently. Now, the point of "leave all
the users who has put a trust in us behind" is a bit of hyperbole IMO.
This community successfully made that transition once before.
>
> I will continue to be proud of our brand, our product and our
> community. And I will continue the work on *Cocoon* towards the future
> in an evolutionary way, so that those who have put their trust in us
> have a reasonable migration path to follow.
I've put a souple years into Cocoon, and I'm proud of the work that I've
done. I like the *concepts* behind Cocoon. The problem is that I lack
the patience to wait for evolution to take place--how long has it been
that real blocks are not a reality in Cocoon? I could understand if it
were just six months and you have to have some time to make it happen.
I take this painfully slow evolutionary pace to mean that we are unable
to adapt quickly enough. That's a real problem. Esp. when I don't have
a clear picture of how blocks is even going to help me.
My friends, the comment of Ruby on Rails and simplicity has hit our
ecosystem. Prepare for an ice age, adapt or die. Slow adaptation isn't
going to cut it. Users have different expectations of their frameworks now.
>
> IMO the most important step towards getting an uppwards spiral again
> is by regaining our and our communities faith in Cocoon, by keeping
> our promisses and do a 2.2 release. Instead of running like lemmlings
> towards the next shiny thing.
>
> We should focus on our core offerning and getting the parts of it
> reusable outside Cocoon and of high quality, following the path
> outlined by Marc.
Enjoy that process. There is a lot of pain involved with doing
restructurings of Cocoon. As much as I like Cocoon, I honestly believe
that the effort to bring order out of chaos is going to be much higher
than the effort to build a new system. That's my two cents.
>
> For you attention seekers out there, OSGi based blocks will draw a lot
> of attention towards Cocoon, and it is innovation, not immitation.
>
> /Daniel
:) Honestly, too little, too late. Just how much attention has OSGi
received over the years? It's been around at least as long as Avalon,
but Avalon received much more attention (albeit negative attention). It
has been living quietly behind the scenes now for a long time.
Re: [RT] The next shiny thing?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
To me:
* throwing away the collected work of the community
* building something rather different
* throwing away a strong brand
* leave all the users who has put a trust in us behind
seem like a rather strange way of "saving" Cocoon.
I will continue to be proud of our brand, our product and our community.
And I will continue the work on *Cocoon* towards the future in an
evolutionary way, so that those who have put their trust in us have a
reasonable migration path to follow.
IMO the most important step towards getting an uppwards spiral again is
by regaining our and our communities faith in Cocoon, by keeping our
promisses and do a 2.2 release. Instead of running like lemmlings
towards the next shiny thing.
We should focus on our core offerning and getting the parts of it
reusable outside Cocoon and of high quality, following the path outlined
by Marc.
For you attention seekers out there, OSGi based blocks will draw a lot
of attention towards Cocoon, and it is innovation, not immitation.
/Daniel
Ugo Cei wrote:
> Il giorno 06/dic/05, alle ore 01:24, David Crossley ha scritto:
>
>>> I started to draft here what the next-generation Cocoon should be. I
>>> dubbed it "Racoon" (with Andrew's permission) as I really think that
>>> from a marketing point of view, a new name should be used so that
>>> people
>>> don't see it as a publication engine, as too many people still see
>>> Cocoon.
>>
>>
>> Please don't. Cocoon is the name.
>
> I agree that we must keep the Cocoon name, but even if we decide to
> change it in the end, please not "Racoon". From a marketing
> standpoint, it will always be interpreted as meaning "almost like
> Rails, but not the real thing".
Re: [RT] The next shiny thing?
Posted by hepabolu <he...@gmail.com>.
Bertrand Delacretaz wrote:
> Le 6 déc. 05, à 10:12, Ugo Cei a écrit :
>
>> ...I also see "Too soon" on that list, which might be descriptive of
>> the feelings of some people on this list ;).
>
>
> It might be too soon to choose a name for something which doesn't exist
> yet...but choosing a "code name" helps clarifying what we're talking about.
>
> So Racoon (or whatever name) could be the code name, it doesn't mean
> this would ever by shipped under that name.
BTW the animal's name is raccoon (2 c's).
I agree that now is not the time for a new name and there's always the
way of Debian and Ubuntu to provide names to releases while the overall
name stays the same.
Bye, Helma
Re: [RT] The next shiny thing?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 6 déc. 05, à 10:12, Ugo Cei a écrit :
> ...I also see "Too soon" on that list, which might be descriptive of
> the feelings of some people on this list ;).
It might be too soon to choose a name for something which doesn't exist
yet...but choosing a "code name" helps clarifying what we're talking
about.
So Racoon (or whatever name) could be the code name, it doesn't mean
this would ever by shipped under that name.
-Bertrand
Re: [RT] The next shiny thing?
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
>
> Il giorno 06/dic/05, alle ore 10:01, Sylvain Wallez ha scritto:
>
>> Il like this friendly animal and the rhyme with Cocoon. Now there's
>> also "Baboon" :-)
>>
>> Have a look at
>> http://www.rhymezone.com/r/rhyme.cgi?Word=cocoon&typeofrhyme=perfect&org1=syl&org2=l
>>
>
> I also see "Too soon" on that list, which might be descriptive of the
> feelings of some people on this list ;).
>
> Sorry, couldn't resist.
LOL :-D
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The next shiny thing?
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 06/dic/05, alle ore 10:01, Sylvain Wallez ha scritto:
> Il like this friendly animal and the rhyme with Cocoon. Now there's
> also "Baboon" :-)
>
> Have a look at http://www.rhymezone.com/r/rhyme.cgi?
> Word=cocoon&typeofrhyme=perfect&org1=syl&org2=l
I also see "Too soon" on that list, which might be descriptive of the
feelings of some people on this list ;).
Sorry, couldn't resist.
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine & Food Blog: http://www.divinocibo.it/
Re: [RT] The next shiny thing?
Posted by Sylvain Wallez <sy...@apache.org>.
Ugo Cei wrote:
>
> Il giorno 06/dic/05, alle ore 01:24, David Crossley ha scritto:
>
>>> I started to draft here what the next-generation Cocoon should be. I
>>> dubbed it "Racoon" (with Andrew's permission) as I really think that
>>> from a marketing point of view, a new name should be used so that
>>> people
>>> don't see it as a publication engine, as too many people still see
>>> Cocoon.
>>
>> Please don't. Cocoon is the name.
>
> I agree that we must keep the Cocoon name, but even if we decide to
> change it in the end, please not "Racoon". From a marketing
> standpoint, it will always be interpreted as meaning "almost like
> Rails, but not the real thing".
Il like this friendly animal and the rhyme with Cocoon. Now there's also
"Baboon" :-)
Have a look at
http://www.rhymezone.com/r/rhyme.cgi?Word=cocoon&typeofrhyme=perfect&org1=syl&org2=l
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The next shiny thing?
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 06/dic/05, alle ore 01:24, David Crossley ha scritto:
>> I started to draft here what the next-generation Cocoon should be. I
>> dubbed it "Racoon" (with Andrew's permission) as I really think that
>> from a marketing point of view, a new name should be used so that
>> people
>> don't see it as a publication engine, as too many people still see
>> Cocoon.
>
> Please don't. Cocoon is the name.
I agree that we must keep the Cocoon name, but even if we decide to
change it in the end, please not "Racoon". From a marketing
standpoint, it will always be interpreted as meaning "almost like
Rails, but not the real thing".
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine & Food Blog: http://www.divinocibo.it/
Re: [RT] The next shiny thing?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 06.12.2005 13:18, Steven Noels wrote:
> I'm
> surprised to finally see evidence of an anti-OSGI camp in Cocoon. Not
> that this surprises me, but it's just sad that this hasn't been
> clarified much earlier. That damned community tax again, I guess. Waste
> of time and energy for everyone.
At least for me it is more a "I'm not happy with 'yet another beast',
but I can't provide another solution." I did not work with any container
up to recently, so how should I take part in such a discussion? At the
end it is probably even an "I don't care." as I can't read about and
evaluate everything and have to care about other things in my work with
Cocoon.
Jörg
Re: [RT] The next shiny thing?
Posted by Sylvain Wallez <sy...@apache.org>.
Steven Noels wrote:
> On 06 Dec 2005, at 12:04, Sylvain Wallez wrote:
>
>> Steven Noels wrote:
>>> On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
>>>
>>>> Struts has Shale
>>>
>>> Meeep. Buzzzz. Wrong.
>>>
>>> Struts has Craig.
>>
>> And Tapestry has Howard and Spring has Rod. What do you mean?
>
> I meant to say that Struts is a bad example since it has a benevolent,
> dedicated person that is cheered upon by a league of grateful
> groupies, who will follow him anywhere (up to their own imagination's
> limits). Ditto with Tapestry and Spring and RoR. With Cocoon, there's
> as much direction as there's developers, and users even: it's big and
> bloated and lacks direction. And I honestly believe it's the community
> and consensus tax which make it virtually impossible to create such a
> unified direction. So so far, I believe we're about to say the same
> thing, except that I'm pessimistic (as usual).
Ok. Got it. Also, after hitting "send", I realized that I should have
added "and Daisy has Bruno".
> But you sniped away what I really meant to say, actually. That blocks
> and interfaces, however they come to into existence, are needed - not
> only for technical but mostly for community reasons: to provide
> non-community-shepherded code with its own release and life cycle. To
> provide users with something they can rely upon. Not the next cool
> thing down the road, or an experimentation platform for non-enduring
> geeks. Or a code graveyard for a bunch of consultants.
I wholeheartedly agree. The purpose of layering Cocoon is about ensuring
strength of contracts. Someone that knows a piece of software inside out
doesn't need contracts. But others do.
This is the well-known architecture of participation ([1] -- funny to
see who's quoted) that says that successful communities keep a center
cathedral around which the bazaar can develop. Lately, Cocoon has failed
to maintain this cathedral which has been slowly invaded by the bazaar.
Defining contracts in separate modules, and defending them fiercely
through human oversight and automated tools is a way to help the very
decentralized Cocoon community to preserve the central cathedral. The
document I added to Daisy has a chapter dedicated do development rules,
which is new here.
> I fail to see how giving something fancy names will change that model.
Fancy names are meant to show that something different is going on.
Technically different, but also more importantly culturally different.
And that last point is certainly a more difficult change. Some will like
it, others won't.
> So consequentially, maybe it's the community that needs to change.
It a least must change the way it handles what it produces and how it
behaves.
> I'm surprised to finally see evidence of an anti-OSGI camp in Cocoon.
> Not that this surprises me, but it's just sad that this hasn't been
> clarified much earlier.
It's not an anti-OSGi camp, but a "are blocks really the solution?"
camp. OSGi was brought to the picture because no one could agree on the
kernel/container to use. So we fetched a great ready-made container outside.
> That damned community tax again, I guess. Waste of time and energy for
> everyone.
Maybe. But that community also has been able to produce many great
things. Let's try to build this cathedral so that the community bazaar
can builds even greater things around it.
Sylvain
[1] http://weblogs.oreilly.com/lpt/wlg/3017
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The next shiny thing?
Posted by Steven Noels <st...@outerthought.org>.
On 06 Dec 2005, at 12:04, Sylvain Wallez wrote:
> Steven Noels wrote:
>> On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
>>
>>> Struts has Shale
>>
>> Meeep. Buzzzz. Wrong.
>>
>> Struts has Craig.
>
> And Tapestry has Howard and Spring has Rod. What do you mean?
I meant to say that Struts is a bad example since it has a benevolent,
dedicated person that is cheered upon by a league of grateful groupies,
who will follow him anywhere (up to their own imagination's limits).
Ditto with Tapestry and Spring and RoR. With Cocoon, there's as much
direction as there's developers, and users even: it's big and bloated
and lacks direction. And I honestly believe it's the community and
consensus tax which make it virtually impossible to create such a
unified direction. So so far, I believe we're about to say the same
thing, except that I'm pessimistic (as usual).
But you sniped away what I really meant to say, actually. That blocks
and interfaces, however they come to into existence, are needed - not
only for technical but mostly for community reasons: to provide
non-community-shepherded code with its own release and life cycle. To
provide users with something they can rely upon. Not the next cool
thing down the road, or an experimentation platform for non-enduring
geeks. Or a code graveyard for a bunch of consultants.
I fail to see how giving something fancy names will change that model.
So consequentially, maybe it's the community that needs to change. I'm
surprised to finally see evidence of an anti-OSGI camp in Cocoon. Not
that this surprises me, but it's just sad that this hasn't been
clarified much earlier. That damned community tax again, I guess. Waste
of time and energy for everyone.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought Open Source Java & XML
stevenn at outerthought.org stevenn at apache.org
Re: [RT] The next shiny thing?
Posted by Sylvain Wallez <sy...@apache.org>.
Steven Noels wrote:
> On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
>
>> Struts has Shale
>
> Meeep. Buzzzz. Wrong.
>
> Struts has Craig.
And Tapestry has Howard and Spring has Rod. What do you mean? That
Cocoon misses someone that can fully dedicate to it and plays the
benevolent dictator?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The next shiny thing?
Posted by Steven Noels <st...@outerthought.org>.
On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
> Struts has Shale
Meeep. Buzzzz. Wrong.
Struts has Craig.
It's a telltale of Cocoon's problem that we're off discussing marketing
techniques and branding again, without having any design, code, nor
dedication to boot with. A busy thread just in time for ACon.
Currently, I see more community than project in Cocoon.
I'm game for any sort of progress, as long as:
* there's a core set of functionality which is documented through
maintained API (or conventions) and scripture
* there's a mechanism which enables us to separate the unmaintained
one-off's aka blocks into separate release and deprecation cycles
* there's more than one actual coder who actually lives through this
until the end
Maybe this might show people something. This is the reality of someone
building an application (Daisy) with a UI using Cocoon:
#include.block.batik=false
#include.block.fop=false
#include.block.ajax=false
#include.block.apples=false
#include.block.forms=false
#include.block.serializers=false
, with ajax currently only being included since forms apparently depend
on it. And Batik is just there to render images in FOP. That's all.
Furthermore, in
http://svn.cocoondev.org/viewsvn/trunk/daisy/applications/daisywiki/
frontend/src/cocoon/webapp/daisy/sitemap.xmap:
org.outerj.daisy.frontend.QueryGenerator
org.outerj.daisy.frontend.ErrorGenerator
org.outerj.daisy.frontend.DaisyLinkTransformer
org.outerj.daisy.frontend.FopImageSrcTransformer
org.outerj.daisy.frontend.TableHelperTransformer
org.outerj.daisy.frontend.IncludePreparedDocumentsTransformer
org.outerj.daisy.frontend.ExternalIncludeTransformer
org.outerj.daisy.frontend.PublisherTransformer
org.outerj.daisy.frontend.IDAbsolutizerTransformer
org.outerj.daisy.frontend.SerializeTransformer
org.outerj.daisy.frontend.CrossRefParserTransformer
org.outerj.daisy.repository.DocumentReadDeniedException
org.outerj.daisy.repository.DocumentNotFoundException
org.outerj.daisy.repository.DocumentVariantNotFoundException
org.outerj.daisy.frontend.util.HttpMethodNotAllowedException
org.outerj.daisy.frontend.SetRequestAttributeAction
org.outerj.daisy.frontend.LocaleAction
org.outerj.daisy.frontend.MountPointAction
org.outerj.daisy.frontend.InitSkinAction
org.outerj.daisy.frontend.SkinsDirAction
org.outerj.daisy.frontend.HandleSiteAction
org.outerj.daisy.frontend.PartReader
org.outerj.daisy.frontend.components.reading.CachingReader
Looking at that sitemap and the tiny list of used blocks, I see a
number of things:
* there's a need for solid programming interfaces in Cocoon
* there's lots of stuff we don't use
Maybe, when we start from scratch, building solid interfaces, throwing
away undermaintained legacy, this is a good time to reinvent Cocoon
into a workable environment again. But IMNSHO, we'll never get there
with the current approach, effort and dedication. It's the amount of
community and legacy tax that is putting innovation efforts into
starvation.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought Open Source Java & XML
stevenn at outerthought.org stevenn at apache.org
Re: [RT] The next shiny thing?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 6 déc. 05, à 10:17, Matthew Langham a écrit :
> Where is the vision?
Delivering some of the unique things that are inside Cocoon in much
smaller independent packages, to make them useful to people who don't
need all of Cocoon.
Dunno if this qualifies as a vision, but it's how I see it ;-)
-Bertrand
Re: [RT] The next shiny thing?
Posted by Sylvain Wallez <sy...@apache.org>.
Matthew Langham wrote:
>> No, the brand is not strong.
>>
>> Look around among people that have *not* used Cocoon and ask
>> them what it is. Most of them will tell you "it's a
>> publishing engine", or even "it's a tool to perform XSL
>> transformations".
>>
>> What we have now and what we're building is much more than
>> that, and IMO we won't be able to deliver this message with a
>> name that has been associated for 6 years to "just" a
>> publication engine, even if that "just" is already a lot.
>>
>> Struts has Shale which is a complete rewrite that learns from
>> the past and looks into the future. I really think we should
>> to the same. We're talking a new start, aiming at building a
>> simple, clean and consistent platform. That deserves more
>> than in a major revision number of a name that denotes
>> something else in most people's mind.
>>
>>
>
> I strongly disagree with this. And while I agree to most of the points being
> discussed, I can't help but feel that is is a step too far.
>
> And I also think the current discussion is missing something significant
> (when compared to the first Cocoon steps). While only being able to quickly
> read through all the discussions - if the best way is really for a clean
> start:
>
> Where is the vision?
>
It's being built in this thread, and I started aggregating it on
Daisy[1]. Still very embryonic, but I will spend time on it.
Now you're right: let's forget this naming issue, even if I really
consider it as being important, and concentrate on what it we want to build.
Sylvain
[1] http://cocoon.zones.apache.org/daisy/test/g1/792.html
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
RE: [RT] The next shiny thing?
Posted by Matthew Langham <ml...@s-und-n.de>.
>
> No, the brand is not strong.
>
> Look around among people that have *not* used Cocoon and ask
> them what it is. Most of them will tell you "it's a
> publishing engine", or even "it's a tool to perform XSL
> transformations".
>
> What we have now and what we're building is much more than
> that, and IMO we won't be able to deliver this message with a
> name that has been associated for 6 years to "just" a
> publication engine, even if that "just" is already a lot.
>
> Struts has Shale which is a complete rewrite that learns from
> the past and looks into the future. I really think we should
> to the same. We're talking a new start, aiming at building a
> simple, clean and consistent platform. That deserves more
> than in a major revision number of a name that denotes
> something else in most people's mind.
>
I strongly disagree with this. And while I agree to most of the points being
discussed, I can't help but feel that is is a step too far.
And I also think the current discussion is missing something significant
(when compared to the first Cocoon steps). While only being able to quickly
read through all the discussions - if the best way is really for a clean
start:
Where is the vision?
Matthew
Re: [RT] The next shiny thing?
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
> David Crossley wrote:
>
<snip/>
>> Please don't. Cocoon is the name
> +1, same opinion here
> the brand is strong enough, and can cope with major release numbers that indicate we had serious new insights
>
No, the brand is not strong.
Look around among people that have *not* used Cocoon and ask them what
it is. Most of them will tell you "it's a publishing engine", or even
"it's a tool to perform XSL transformations".
What we have now and what we're building is much more than that, and IMO
we won't be able to deliver this message with a name that has been
associated for 6 years to "just" a publication engine, even if that
"just" is already a lot.
Struts has Shale which is a complete rewrite that learns from the past
and looks into the future. I really think we should to the same. We're
talking a new start, aiming at building a simple, clean and consistent
platform. That deserves more than in a major revision number of a name
that denotes something else in most people's mind.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The next shiny thing?
Posted by Reinhard Poetz <re...@yahoo.de>.
--- Marc Portier <mp...@outerthought.org> schrieb:
>
>
> David Crossley wrote:
> > Sylvain Wallez wrote:
> >
> >>Peter Hunsberger wrote:
> >>
> >><snip/>
> >>
> >>>Perhaps an area on the Wiki to discuss straw man
> features and
> >>>requirements for a 3.0 release would be a good
> thing?
> >>
> >>See
>
http://cocoon.zones.apache.org/daisy/test/g1/792.html
> (BTW, how do
> >>we create a new book in Daisy?)
> >>
> >>I started to draft here what the next-generation
> Cocoon should be. I
> >>dubbed it "Racoon" (with Andrew's permission) as I
> really think that
> >>from a marketing point of view, a new name should
> be used so that people
> >>don't see it as a publication engine, as too many
> people still see Cocoon.
> >
> >
> > Please don't. Cocoon is the name.
> >
>
> +1, same opinion here
> the brand is strong enough, and can cope with major
> release numbers that
> indicate we had serious new insights
I don't think we should give it a release number
*now*. We don't know much about what this new Cocoon
will be, when it will be released and we don't know if
we really have to start from scratch. I think we
underestimate the impact of getting blocks and with
them cleaner contracts how to extend Cocoon very soon
and maybe we can go a more evolutionary path than most
of us think.
--
Reinhard
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: [RT] The next shiny thing?
Posted by Marc Portier <mp...@outerthought.org>.
David Crossley wrote:
> Sylvain Wallez wrote:
>
>>Peter Hunsberger wrote:
>>
>><snip/>
>>
>>>Perhaps an area on the Wiki to discuss straw man features and
>>>requirements for a 3.0 release would be a good thing?
>>
>>See http://cocoon.zones.apache.org/daisy/test/g1/792.html (BTW, how do
>>we create a new book in Daisy?)
>>
>>I started to draft here what the next-generation Cocoon should be. I
>>dubbed it "Racoon" (with Andrew's permission) as I really think that
>>from a marketing point of view, a new name should be used so that people
>>don't see it as a publication engine, as too many people still see Cocoon.
>
>
> Please don't. Cocoon is the name.
>
+1, same opinion here
the brand is strong enough, and can cope with major release numbers that
indicate we had serious new insights
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [RT] The next shiny thing?
Posted by David Crossley <cr...@apache.org>.
Sylvain Wallez wrote:
> Peter Hunsberger wrote:
>
> <snip/>
>
> >Perhaps an area on the Wiki to discuss straw man features and
> >requirements for a 3.0 release would be a good thing?
>
> See http://cocoon.zones.apache.org/daisy/test/g1/792.html (BTW, how do
> we create a new book in Daisy?)
>
> I started to draft here what the next-generation Cocoon should be. I
> dubbed it "Racoon" (with Andrew's permission) as I really think that
> from a marketing point of view, a new name should be used so that people
> don't see it as a publication engine, as too many people still see Cocoon.
Please don't. Cocoon is the name.
-David
Re: [RT] The next shiny thing?
Posted by Sylvain Wallez <sy...@apache.org>.
Peter Hunsberger wrote:
<snip/>
> Perhaps an area on the Wiki to discuss straw man features and
> requirements for a 3.0 release would be a good thing?
See http://cocoon.zones.apache.org/daisy/test/g1/792.html (BTW, how do
we create a new book in Daisy?)
I started to draft here what the next-generation Cocoon should be. I
dubbed it "Racoon" (with Andrew's permission) as I really think that
from a marketing point of view, a new name should be used so that people
don't see it as a publication engine, as too many people still see Cocoon.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The next shiny thing?
Posted by Peter Hunsberger <pe...@gmail.com>.
On 12/4/05, Ralph Goers <Ra...@dslextreme.com> wrote:
> Sylvain Wallez wrote:
>
> > To last for a long time, a company/community has to make sure it has
> > some customers/users. The new features in 2.2, if you look at them are
> > more about managing complexity than bringing real new stuff. Is it
> > something that will bring lots of new users? I don't think so.
> >
> > So although we have to maintain the current code base, we also have to
> > think about what should be our next offering.
>
> Well, of course you are right. But the problem is we haven't finished
> 2.2 and you're talking 3.0. Let's get 2.2 out the door and then talk
> about 3.0.
>
I think it makes some sense to start talking about what a 3.0 might
look like. Two main reason for that:
First, it is good to always have a long term architectural direction
in front of you. It is one of the ways to help keep the community
focused on what they are doing now and where they want to go in thhe
future.
Second, it helps truly indicate that the 2.1 branch is really moving
into maintenance mode.
At this point, it wouldn't hurt the community to come to some
agreement about what the fundamental requirements are for a 3.0. OTOH,
discussion about implementation would seem premature until the 2.2
branch has been shown to not be able to support all the capabilities
the community wants to implement.
Perhaps an area on the Wiki to discuss straw man features and
requirements for a 3.0 release would be a good thing? Basically, the
3.0 discussion could be used to keep track of features and
capabilities the community agrees are good things, but for some reason
(architectural, structural, lack of time) doesn't want to do in the
2.2 branch. Some of the 3.0 features might later migrate into a 2.x
branch or they may never go anywhere, but the discussion itself helps
to keep everyone focused on what is needed now vs. what could be done
in the future...
--
Peter Hunsberger
Re: [RT] The next shiny thing?
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
> To last for a long time, a company/community has to make sure it has
> some customers/users. The new features in 2.2, if you look at them are
> more about managing complexity than bringing real new stuff. Is it
> something that will bring lots of new users? I don't think so.
>
> So although we have to maintain the current code base, we also have to
> think about what should be our next offering.
Well, of course you are right. But the problem is we haven't finished
2.2 and you're talking 3.0. Let's get 2.2 out the door and then talk
about 3.0.
Ralph
Re: [RT] The next shiny thing?
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> To last for a long time, a company/community has to make sure it has
> some customers/users. The new features in 2.2, if you look at them are
> more about managing complexity than bringing real new stuff. Is it
> something that will bring lots of new users? I don't think so.
>
I'm not sure - we already have so many features that are hard to use. If
all of this would be more easily usable, I think this would bring us new
users. Just "throwing in new features" will imho not attract new users
*if* everything remains as complicated as it is right now.
> So although we have to maintain the current code base, we also have to
> think about what should be our next offering.
>
Yepp. So how do we proceed from here? We have an unfinished 2.2 and are
talking about 3.0. Now, I always thought of 2.2 as a milestone to 3.0
(or to real blocks). In fact, I think 2.2 makes many things much more
easier: the configuration is easier, updating Cocoon is easier, we
hopefully have a good way for build/deployment, per sitemap
configurations, classloading etc. All of this helps *a lot*.
So, imho, we should really get 2.2 out of the door - while discussing a
possible 3.0. As far as I remember, Cocoon 2.0 was designed/discussed
first and then implemented. A vision (roadmap) existed and I think we
should build up our vision of 3.0 first before quickly adding something
which will only bring some relief in the short term.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] The next shiny thing?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
>
> <snip/>
>
>> Start a whiteboard prototype if you feel like it, but to me it seem
>> quite risky to try to rewrite everything from scratch, although I
>> have felt the urge myself countless time while struggling with the
>> messy internals. But before you go ahead and rewrite everything from
>> scratch, take some minutes and read why Joel Spolesky thinks that
>> rewriting software from scratch is the:
>>
>> *single worst strategic mistake* that any software company can make
>>
>> http://www.joelonsoftware.com/articles/fog0000000069.html.
>
>
> Although I most often find Joel Spolsky's writings very enlightning, I
> always disagreed with that one. And to understand why, consider what
> is your main browser and what mail software you used to write this.
> The headers say "User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)".
Sure, I'm an early adaptor, otherwise I wouldn't be here. Still, no one
talks about Netscape anymore, so for them it doesn't seem like such a
wise decision. I'm not attracted of betting a 2.2 with a lot of usefull
features and that we can deliver within a few months, if we focus,
against a leap of faith.
> <snip/>
>
>> Leaving our core offering and rewriting everything from scratch means
>> community and product suicide, don't do it.
>
> To last for a long time, a company/community has to make sure it has
> some customers/users.
We have customers as they need what we deliver now. Alienating them by
first not improving what they use for a couple of years and then,
possibly, deliver something entierly different seem like rather strange
customer relationship management.
As a community we are gathered around what Cocoon happen to be and
(maybe unfortunately) around our interest in the next trend. What says
that we would have a common interest in something that is a revolution
rather than an evolution?
I for one wouldn't.
> The new features in 2.2, if you look at them are more about managing
> complexity than bringing real new stuff.
You know Sylvain, managing complexity is one of the hardest and most
complicated problems there are. And failing, to different degrees, to
manage complexity in software projects costs the companies and
organizations of the world unbelieveable amounts of money.
And with what we are about to finish if people just can stop distracting
themself and instead focus for a short while, will bring new levels of
complexity management to webapps. It is worth increadibly much more than
just adding some new half baked buzzword compability.
> Is it something that will bring lots of new users? I don't think so.
>
> So although we have to maintain the current code base, we also have to
> think about what should be our next offering.
Our next offering is Cocoon 2.2 and we at least had a common plan for
what it should contain, I will continue to follow that plan and I hope
others will. For the offering after that, sure we discuss that as well,
actually that seem to be our main occupation.
We need to finish things also.
And I completely fail to see why the stuff that you propose would need a
completely new code base. AFAICS, and as I have discussed and thought
extensively about, and in some cases partly implemented some of the
stuff, I'm pretty sure that I know what I'm talking about.
Exactly what hinder you or anyone else to add the new ideas incrementally?
/Daniel
Re: [RT] The next shiny thing?
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
<snip/>
> Start a whiteboard prototype if you feel like it, but to me it seem
> quite risky to try to rewrite everything from scratch, although I have
> felt the urge myself countless time while struggling with the messy
> internals. But before you go ahead and rewrite everything from
> scratch, take some minutes and read why Joel Spolesky thinks that
> rewriting software from scratch is the:
>
> *single worst strategic mistake* that any software company can make
>
> http://www.joelonsoftware.com/articles/fog0000000069.html.
Although I most often find Joel Spolsky's writings very enlightning, I
always disagreed with that one. And to understand why, consider what is
your main browser and what mail software you used to write this. The
headers say "User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)".
<snip/>
> Leaving our core offering and rewriting everything from scratch means
> community and product suicide, don't do it.
To last for a long time, a company/community has to make sure it has
some customers/users. The new features in 2.2, if you look at them are
more about managing complexity than bringing real new stuff. Is it
something that will bring lots of new users? I don't think so.
So although we have to maintain the current code base, we also have to
think about what should be our next offering.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] The next shiny thing?
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> The main problem with our community, IMO, is the lack of focus and
> persistance. We have so many great ideas, but as large parts of the
> community always are running towards the next shiny thing and have very
> little interest in polishing the design, contracts and implementations.
> We are left with an ever accumulating bunch of half baked ideas with
> prototype implementations that makes it so frustrating to develop Cocoon.
>
> After having been around for a couple of years, I start to recognize our
> development cycle: First a new sexy idea is suggested, and we all jumps
> up and down shouting out our excitement. Then we might start to discuss
> design and implementation, and most people lose interest or maybe drop
> by and complains about that the discussion have become technical and
> that it bire them stiff. After that some people might even implement it.
> And as it often takes a lot of work to design and implement cool stuff
> it takes a while. And when it finally start to get somewhere, people are
> not even remotely interested anymore because there is something new and
> shiny to jump up and down and shout about.
>
> IMO, what I described above is the main source of our problems today.
> Instead of focus on our core ideas and functionalities, and ensure that
> we have real high quality implementations of them, we just add still
> another prototype implementation of something new whithout bothering
> about how it integrates with the rest of what we have. And we as a
> community doesn't take repsonse in getting things smooth and coherent.
>
> --- o0o ---
>
> So I'm sorry, I will not jump up and down and shout together with the
> rest of you this time. I will persist and continue with the work in
> trunk on what I think is important:
>
> * finishing blocks
> * make the m2 build system work and become the only one
> * binary releases
> * strengthen the contracts
> * improve the quality
> * split up Cocoon in smaller parts
> * deprecate things that not are or not should be used anymore
> * strive for coherence
> * refactoring and rearchitecturing mercelesly
> * 2.2 during Q1
>
> This work will continue to be evolutionary and incremental. And when we
> have the block system and have cleaned the contracts and the messy
> implementation of the core, it will be easy and safe to experiment with
> new great ideas. And we are getting rather close to this point, we just
> need to finish what we have started. And for the messines we solve that
> with refactoring.
>
> --- o0o ---
>
> Start a whiteboard prototype if you feel like it, but to me it seem
> quite risky to try to rewrite everything from scratch, although I have
> felt the urge myself countless time while struggling with the messy
> internals. But before you go ahead and rewrite everything from scratch,
> take some minutes and read why Joel Spolesky thinks that rewriting
> software from scratch is the:
>
> *single worst strategic mistake* that any software company can make
>
> http://www.joelonsoftware.com/articles/fog0000000069.html.
>
> I suggest that we who want a 2.2 during Q1 continue to work together on
> getting there.
>
> --- o0o ---
>
> For the actual functionality that Sylvain proposed I think much of it is
> great and I have argued for things similar to some of them earlier. And
> they can be added in an incremental way.
>
> But even if I would love to discuss the techical details. And how well
> pluggable controllers will fit into the blocks architecture. And how
> cool stuff one can do with pull parsing, especially if we use AXIOM from
> Axis2, there are more important things to discuss right now:
>
> Leaving our core offering and rewriting everything from scratch means
> community and product suicide, don't do it.
>
> /Daniel
Just can say, thanks, thanks, thanks Daniel for this mail!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
[RT] The next shiny thing?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
The main problem with our community, IMO, is the lack of focus and
persistance. We have so many great ideas, but as large parts of the
community always are running towards the next shiny thing and have very
little interest in polishing the design, contracts and implementations.
We are left with an ever accumulating bunch of half baked ideas with
prototype implementations that makes it so frustrating to develop Cocoon.
After having been around for a couple of years, I start to recognize our
development cycle: First a new sexy idea is suggested, and we all jumps
up and down shouting out our excitement. Then we might start to discuss
design and implementation, and most people lose interest or maybe drop
by and complains about that the discussion have become technical and
that it bire them stiff. After that some people might even implement it.
And as it often takes a lot of work to design and implement cool stuff
it takes a while. And when it finally start to get somewhere, people are
not even remotely interested anymore because there is something new and
shiny to jump up and down and shout about.
IMO, what I described above is the main source of our problems today.
Instead of focus on our core ideas and functionalities, and ensure that
we have real high quality implementations of them, we just add still
another prototype implementation of something new whithout bothering
about how it integrates with the rest of what we have. And we as a
community doesn't take repsonse in getting things smooth and coherent.
--- o0o ---
So I'm sorry, I will not jump up and down and shout together with the
rest of you this time. I will persist and continue with the work in
trunk on what I think is important:
* finishing blocks
* make the m2 build system work and become the only one
* binary releases
* strengthen the contracts
* improve the quality
* split up Cocoon in smaller parts
* deprecate things that not are or not should be used anymore
* strive for coherence
* refactoring and rearchitecturing mercelesly
* 2.2 during Q1
This work will continue to be evolutionary and incremental. And when we
have the block system and have cleaned the contracts and the messy
implementation of the core, it will be easy and safe to experiment with
new great ideas. And we are getting rather close to this point, we just
need to finish what we have started. And for the messines we solve that
with refactoring.
--- o0o ---
Start a whiteboard prototype if you feel like it, but to me it seem
quite risky to try to rewrite everything from scratch, although I have
felt the urge myself countless time while struggling with the messy
internals. But before you go ahead and rewrite everything from scratch,
take some minutes and read why Joel Spolesky thinks that rewriting
software from scratch is the:
*single worst strategic mistake* that any software company can make
http://www.joelonsoftware.com/articles/fog0000000069.html.
I suggest that we who want a 2.2 during Q1 continue to work together on
getting there.
--- o0o ---
For the actual functionality that Sylvain proposed I think much of it is
great and I have argued for things similar to some of them earlier. And
they can be added in an incremental way.
But even if I would love to discuss the techical details. And how well
pluggable controllers will fit into the blocks architecture. And how
cool stuff one can do with pull parsing, especially if we use AXIOM from
Axis2, there are more important things to discuss right now:
Leaving our core offering and rewriting everything from scratch means
community and product suicide, don't do it.
/Daniel
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Ugo Cei <ug...@apache.org>.
Sylvain,
I'm glad to see that, more than one year after my "Butterfly
Manifesto" [1], people are finally coming to the realization that we
need a revolutionary change in Cocoon, a change that is targeted
towards a radical simplification. Better late than never :-).
In order to proceed from here, I think we need to decide what we want
Cocoon to be. At present, I see Cocoon as wanting to be at least
three different things, all together:
1) A web publishing framework.
2) A web application framework
3) An XML-based sort of engine or hub for producing and consuming web
services.
Personally, I'm not that much interested in either 1 or 3 above, even
though my next project assignment will probably involve building a
publishing system for producing a printed book and people are trying
to push me towards using Cocoon for doing 3.
But I think 1 isn't particularly fun and can be tackled using Cocoon
2.1, and there are probably better solutions for 3 already. Which
leaves us with 2, which isn't all that bad if what you want is build
the next great Web 2.0 service, earn a decent income selling
subscriptions or ad space, and later make a boatload of money by
selling to Google, Yahoo or Microsoft ;). Or even if you want to
provide applications for your customers or for your internal IT
department, which is probably what most of us do day in, day out.
To reach this elusive goal, we need a platform that makes it easy to
support Ajax and to provide and consume RESTful web services. We need
it to be agile, as in needing the shortest roundtrip time between
doing an edit and seeing its efffect in a browser window. We need to
support a simple persistance mechanism on top of SQL, like
ActiveRecord (jDBI looks great for this, but we must leave the door
open for people wanting to use Hibernate or JDO or whatever).
I agree we need a simple API for the sitemap that makes pipelines
composable and content-aware. With such an API, it will be easy to
provide either a declarative sitemap configuration file or a
programmatic one, using any scripting language that runs on the JVM.
I'd also like the controller to be able to adopt the Ajax paradigm
(actually the "Asynchronous XML over HTTP" part of it). By this I
mean that it should be possible to use something similar to the
XMLHttpRequest object to invoke an external service, process the
response using DOM or StAX and, once all pending requests have been
satisfied, serve the response to the client. Great for doing mashups.
I know it's premature to talk about implementation issues, but since
Carsten brought up the issue first, y'all know I have a fondness for
Spring, so you know where my heart lies.
To Daniel and the others working on Cocoon 2.2: You have a tough job
ahead and it's going to get even tougher now that everyone is jumping
up and down around this new shiny thing. I'm afraid you're not going
to get much help from others, but what you're doing is incredibly
valuable for all those companies that have an interest in supporting
existing Cocoon 2 solutions, which will be around for a long time. I
think what these companies should do is to directly and financially
support this effort. It's not going to be fun (for most people, I
mean) and it's not going to be rewarded by immense popularity and
recognition, so I think it has to be paid for.
Just my 0.02€,
Ugo
[1]: http://wiki.apache.org/cocoon/ButterflyManifesto
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine & Food Blog: http://www.divinocibo.it/
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> To answer your question : you're fully ON track, and, naive as it may
> sound, count me in for the this great new thing !
Me too, but only if it's an evolution and not a revolution. We have clear goals
to shrink Cocoon to a "core" and thanks to Daniel we have got the last missing
major feature implementated (block-level components) and we finally can start to
break up things.
This will result in a small core which will be the major benefit of Cocoon 2.2
and can be a good starting point for all the ideas swirling around.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Jorg Heymans <jh...@domek.be>.
Sylvain Wallez wrote:
> -- oOo --
>
> Ok, thanks reading so far.
>
> My impression is that with all these changes, Cocoon will be sexy again.
> Add a bit of runtime analysis of databases and automatic generation of
> CForms to the picture, and you have something that has the same
> productivity as RoR, but in a J2EE environment. It also includes what I
> learned when working on Ajax and the consequences it has on the overall
> system architecture.
>
> You certainly have noticed that the above is more about the controller
> than about the sitemap. This is because not much changes are needed
> there, except content-aware matchers and selectors. But a more featured
> controller will allow to trash a great number of pipeline components
> that were invented to circumvent controller limitations. The code base
> will shrink.
>
> There are also a number of simplifications that can be done by using
> builtin conventions over configuration, but I'll write about this later.
>
> Tell me your thoughts. Am I completely off-track, or do you also want to
> build this great new thing?
Thanks for stepping up and kicking the bucket once again Sylvain, we've
had a few of these revolution_or_death emails lately and to be honest I
don't think this will be the last one.
Cocoon at this point needs ONE vision and ONE roadmap more than anything
else. Let's not worry now whether we have the momentum to execute such a
radical change, this will come with enthusiasm about the current
direction and clarity thereof.
To answer your question : you're fully ON track, and, naive as it may
sound, count me in for the this great new thing !
Jorg
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Berin Loritsch <bl...@d-haven.org>.
Sylvain Wallez wrote:
> Berin Loritsch wrote:
>
>> There are two antipatterns that I see with Cocoon as a whole (from
>> the current design aspect): Alphabet soup syndrome, and mixed
>> metaphors. The alphabet soup syndrome has to do with the fact that
>> we are buzzword compliant without really taking the time to consider
>> the affects on the whole. The mixed metaphors has to do with all the
>> components that overlap each other such as XMLizable and Generator.
>> Every component should have a reason for being, and it should
>> compliment the other components that already exist. If you want to
>> propose a new component that happens to overlap the responsibility of
>> an existing component it is probably time to see which of the two is
>> really needed. Perhaps the older one needs to be retired.
>>
>> When you look at the sitemap, it is not configuration--even though
>> there is some configuration information in there. A sitemap is a
>> domain specific language expressed in XML. My personal oppinion is
>> that XML is poorly suited for any programming language. The sitemap
>> is a powerful concept--it is the implementation that feels a bit
>> unnatural. Think with the hat of someone who has never looked at
>> Cocoon before. You can probably assume that they have programmed in
>> Java--but that's about it.
>
>
> You can't assume that: Cocoon is also one of the very few frameworks
> that allows people with little programming knowledge to do some
> non-trivial stuff, and we should not loose this goal. That's why I
> consider keeping JavaScript as a glue language something important.
I don't know about you, but the reason most folks I know consider Cocoon
is because it is written in Java. I can guarantee you that not one
non-technical person has ever tried to contribute anything more than a
use-case spec to a Cocoon project I have worked on. Why? Because its
not their job. I would argue that JavaScript is not necessarily easier
than Java. It's different, but not necessarily easier. Your person
with little programming knowlege is going to be just as uneasy with
JavaScript than Java.
The problem with JavaScript has to do with the fact that there is no IDE
support. There is no autocompletion. There is no debugging. There is
no sane way to do test driven development with JavaScript. Sure you get
the scripting easy turn around, but you would also get that with JRuby.
And JRuby has a unit testing framework so it would have a leg up. The
problem with an inconsistent environment is that in order for us to make
it consistent, we would have to create a series of JSR 198 compliant IDE
plugins for the integrated languages. Oh, and wait for IDEs to ship
with JSR 198 support.
I don't think anyone wanting to work on Cocoon is in the IDE business.
When you have one consistent language, you leverage the work of others
for your tool set. Nothing special is required. I honestly believe
that direct interaction with JavaScript is not the way to invite people
with little programming experience. But that's my two cents.
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Berin Loritsch wrote:
> Sylvain Wallez wrote:
>
>> Hi all,
>>
>> For many years, I have been more than happy with Cocoon, enjoying the
>> power and ease it brought for both publication and webapp projects.
>> Over the last months however, other feelings have emerged: there are
>> things that are definitely overly complex in Cocoon, and there have
>> been some emerging frameworks leading to "wow, cool!" reactions
>> rather than "yeah, yet another one". Also, I strongly believe that
>> the Ajax revolution is quickly obsoleting the traditional
>> reload-page-on-user-action model that prevailed on the web up to
>> recently and requires frameworks that help building these new kinds
>> of applications.
>>
>> All this to say that if we want Cocoon to have a bright future, it
>> must go through a mutation. This RT dumps my current ideas about
>> this, depicting something that IMO better fits today's needs while
>> taking into account many years of innovation and what we learned from
>> them.
>
>
> If I may, I'd like to suggest a process for identifying what should
> be, and how to make the design decisions. Bear with me a bit as I use
> something totally unrelated to programming in general.
>
> When a traditional Japanese sword polisher goes about a new project,
> he arranges his tools in his workspace so that he does not have to
> think about which one he needs next. His tools are essentially a set
> of progressively finer grained stones and water. The polisher starts
> with the course grained stones to set the geometry/structure of the
> blade in place. As he works in one small area, he constantly checks
> his work against the whole blade. Uneven, or inconsistent work will
> ruin his efforts. As he progresses toward the fine grained stones, he
> is concentrating on bringing out the subtle detail forged into the
> blade itself. Again, all the time checking his local work against the
> whole.
>
> Now, I said all that to say this:
>
> Simplicity is fun to use, but hard to do. You have to take a process
> like the sword polisher in order to arrive at something brilliantly
> simple. Little things matter. If you can make the user's life even
> just a little bit easier, it is a worthwhile goal. As you add a new
> feature, use it a bit and ask yourself if it is making your life
> easier or harder.
Have a look at the top of http://bluxte.net : "Perfection is achieved
not when there's nothing more to add, but when there's nothing left to
remove."
> There are two antipatterns that I see with Cocoon as a whole (from the
> current design aspect): Alphabet soup syndrome, and mixed metaphors.
> The alphabet soup syndrome has to do with the fact that we are
> buzzword compliant without really taking the time to consider the
> affects on the whole. The mixed metaphors has to do with all the
> components that overlap each other such as XMLizable and Generator.
> Every component should have a reason for being, and it should
> compliment the other components that already exist. If you want to
> propose a new component that happens to overlap the responsibility of
> an existing component it is probably time to see which of the two is
> really needed. Perhaps the older one needs to be retired.
>
> When you look at the sitemap, it is not configuration--even though
> there is some configuration information in there. A sitemap is a
> domain specific language expressed in XML. My personal oppinion is
> that XML is poorly suited for any programming language. The sitemap
> is a powerful concept--it is the implementation that feels a bit
> unnatural. Think with the hat of someone who has never looked at
> Cocoon before. You can probably assume that they have programmed in
> Java--but that's about it.
You can't assume that: Cocoon is also one of the very few frameworks
that allows people with little programming knowledge to do some
non-trivial stuff, and we should not loose this goal. That's why I
consider keeping JavaScript as a glue language something important.
> Now think about the number of technologies that someone has to learn
> in order to be affective with Cocoon. If we have Javascript, Java,
> Jexl, etc. we are introducing complexity and learning curve because we
> haven't thought how to use Java better.
I've been giving another Cocoon training this week, and you cannot know
how each time people are amazed by the power of Cocoon, but frightened
by the number of things they have to learn.
> Think of tools like Hibernate and CForms. Both store metadata in XML
> that can be captured in a Java object or in database metadata. If we
> use Java 5 as the standard minimum JVM for Cocoon 3, we now have
> access to a couple nice features to enhance CForms. Annotations are a
> powerful feature, and we should be looking for ways of using stock
> Java in new and better ways. Why is Ruby on Rails fun to work with?
> It is because things make sense. You only need to learn Ruby to be
> able to create a useful website. You don't need to learn Sitemap
> Markup Language, JEXL, CForms configuration language, Hibernate
> mapping language, Javascript, XML Stylesheet Language, and core
> configuration language.
>
> There is a difference between configuration and convention.
> Convention is the process of describing things by similarity.
> Configuration is the process of describing things by difference.
> Since we can only juggle so much at a time in our minds, guess which
> one wins? I would venture to say that 90% of what goes in the Cocoon
> configuration file is untouched. Why does there have to be a
> configuration item for it then?
And that's even worse: if you look at cocoon.xconf, most of the
configuration that's there is the built-in default, but is put there as
an example of what can be done. The result is a scary file that regular
people modify with the "what will I break this time" fear in mind.
> I think what would be fun, and easier to learn for newbies, is to see
> just how much we can get Java to work _with_ the user instead of
> against them.
Yup.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Berin Loritsch <bl...@citi-us.com>.
On Sunday December 04, 2005 2:49 pm, Joerg Heinicke wrote:
> On 03.12.2005 05:58, Berin Loritsch wrote:
> > Why is Ruby on Rails fun to work with? It is because
> > things make sense. You only need to learn Ruby to be able to create a
> > useful website. You don't need to learn Sitemap Markup Language, JEXL,
> > CForms configuration language, Hibernate mapping language, Javascript,
> > XML Stylesheet Language, and core configuration language.
>
> But don't we agree that RoR works just up to a certain complexity? And
> that targeted Cocoon applications are beyond this complexity? So
> comparing concepts or what to learn to effectively use a technology is a
> bit unfair, isn't it?
>
No, I think that's a cop out. RoR has something that Cocoon *needs*:
simplicity. Web sites don't need to be overly complex. In fact, most
"complex" web sites only need a _little_ bit more than what RoR affords you.
My point is this: Cocoon does not need to be nearly as complex as it is. If
you never stop to see what you can learn from another web framework, you will
always assume that "my needs are just too complex". It just ain't so.
Tell me, why is it so much easier to integrate a web service or two right into
your RoR app compared to a Cocoon app? Ok, maybe that was unfair. How about
automatically generated emails? Oh, again probably a little unfair.
What Cocoon has that is still difficult in RoR is the ability to generate
PDFs. Much of the complexity in Cocoon today is _self_inflicted_. Cocoon is
just not fun to work with. What's wrong with adding a little fun back into
using Cocoon?
Can you give me an example of a web application that you think would be too
complex for rails but just right for Cocoon?
Now, let's go the other way. Create a blog in Cocoon, and compare it with one
written in rails. How much cruft and unnecessary work in each one? Bang for
buck rails kills Cocoon. It doesn't need to be that way.
Bottom line: so what if Cocoon is marketed for stuff more complex than rails?
That's still not an excuse for the complexity we put ourselves through. I
want my work to be fun--or at the very least efficient. You can't be
efficient if you have to learn several languages just to get going. Esp.
since you can't expect to be an expert in any one of them.
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.12.2005 05:58, Berin Loritsch wrote:
> Why is Ruby on Rails fun to work with? It is because
> things make sense. You only need to learn Ruby to be able to create a
> useful website. You don't need to learn Sitemap Markup Language, JEXL,
> CForms configuration language, Hibernate mapping language, Javascript,
> XML Stylesheet Language, and core configuration language.
But don't we agree that RoR works just up to a certain complexity? And
that targeted Cocoon applications are beyond this complexity? So
comparing concepts or what to learn to effectively use a technology is a
bit unfair, isn't it?
Jörg
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Berin Loritsch <bl...@d-haven.org>.
Sylvain Wallez wrote:
> Hi all,
>
> For many years, I have been more than happy with Cocoon, enjoying the
> power and ease it brought for both publication and webapp projects.
> Over the last months however, other feelings have emerged: there are
> things that are definitely overly complex in Cocoon, and there have
> been some emerging frameworks leading to "wow, cool!" reactions rather
> than "yeah, yet another one". Also, I strongly believe that the Ajax
> revolution is quickly obsoleting the traditional
> reload-page-on-user-action model that prevailed on the web up to
> recently and requires frameworks that help building these new kinds of
> applications.
>
> All this to say that if we want Cocoon to have a bright future, it
> must go through a mutation. This RT dumps my current ideas about this,
> depicting something that IMO better fits today's needs while taking
> into account many years of innovation and what we learned from them.
If I may, I'd like to suggest a process for identifying what should be,
and how to make the design decisions. Bear with me a bit as I use
something totally unrelated to programming in general.
When a traditional Japanese sword polisher goes about a new project, he
arranges his tools in his workspace so that he does not have to think
about which one he needs next. His tools are essentially a set of
progressively finer grained stones and water. The polisher starts with
the course grained stones to set the geometry/structure of the blade in
place. As he works in one small area, he constantly checks his work
against the whole blade. Uneven, or inconsistent work will ruin his
efforts. As he progresses toward the fine grained stones, he is
concentrating on bringing out the subtle detail forged into the blade
itself. Again, all the time checking his local work against the whole.
Now, I said all that to say this:
Simplicity is fun to use, but hard to do. You have to take a process
like the sword polisher in order to arrive at something brilliantly
simple. Little things matter. If you can make the user's life even
just a little bit easier, it is a worthwhile goal. As you add a new
feature, use it a bit and ask yourself if it is making your life easier
or harder.
There are two antipatterns that I see with Cocoon as a whole (from the
current design aspect): Alphabet soup syndrome, and mixed metaphors.
The alphabet soup syndrome has to do with the fact that we are buzzword
compliant without really taking the time to consider the affects on the
whole. The mixed metaphors has to do with all the components that
overlap each other such as XMLizable and Generator. Every component
should have a reason for being, and it should compliment the other
components that already exist. If you want to propose a new component
that happens to overlap the responsibility of an existing component it
is probably time to see which of the two is really needed. Perhaps the
older one needs to be retired.
When you look at the sitemap, it is not configuration--even though there
is some configuration information in there. A sitemap is a domain
specific language expressed in XML. My personal oppinion is that XML is
poorly suited for any programming language. The sitemap is a powerful
concept--it is the implementation that feels a bit unnatural. Think
with the hat of someone who has never looked at Cocoon before. You can
probably assume that they have programmed in Java--but that's about it.
Now think about the number of technologies that someone has to learn in
order to be affective with Cocoon. If we have Javascript, Java, Jexl,
etc. we are introducing complexity and learning curve because we haven't
thought how to use Java better.
Think of tools like Hibernate and CForms. Both store metadata in XML
that can be captured in a Java object or in database metadata. If we
use Java 5 as the standard minimum JVM for Cocoon 3, we now have access
to a couple nice features to enhance CForms. Annotations are a powerful
feature, and we should be looking for ways of using stock Java in new
and better ways. Why is Ruby on Rails fun to work with? It is because
things make sense. You only need to learn Ruby to be able to create a
useful website. You don't need to learn Sitemap Markup Language, JEXL,
CForms configuration language, Hibernate mapping language, Javascript,
XML Stylesheet Language, and core configuration language.
There is a difference between configuration and convention. Convention
is the process of describing things by similarity. Configuration is the
process of describing things by difference. Since we can only juggle so
much at a time in our minds, guess which one wins? I would venture to
say that 90% of what goes in the Cocoon configuration file is
untouched. Why does there have to be a configuration item for it then?
I think what would be fun, and easier to learn for newbies, is to see
just how much we can get Java to work _with_ the user instead of against
them.
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
> [snip]
>
>> Tell me your thoughts. Am I completely off-track, or do you also want
>> to build this great new thing?
>
> Well, I've always been against dynamic pipelines and content-aware
> selection. But yes, I've changed my mind.
>
> scripted sitemap, pull-driven events, dynamic pipelines, yes, it's
> time for those.
Great :-)
> Not sure I understand what you mean by flow.sendMultiple() though. can
> you explain in more detail what you mean there?
This is useful in Ajax apps when a user action requires several
different pages to be updated. Right after I sent the RT, I found a blog
entry about the exact same use case I outlined[1].
In many use cases, there are several semi-independent areas in a page.
By semi-independent, I mean that a user action in an area can, but not
always, have an impact on what should be displayed in another area.
In the shopping cart example, there's the catalogue area and the cart
area. When you browse the catalogue, no need to redisplay the cart. But
when you click "add to cart", you need to update both areas: the cart
because its content has changed, and the catalogue to outline the chosen
item and update the available stock.
The knowledge of what areas are to be redisplayed is at the controler
level, e.g. in the "addToCart" flowscript function. So the idea is to
send back to the client a kind of multi-part response, each part being
used to update an area of the browser page.
Technically, this can be implemented by a generator that spits out a
list of <xi:include src="cocoon:/blah"/> to an XInclude transformer,
that will then call the individual pipelines for each of the updated
parts. But that is really overly complicated, hence the idea to allow
the controller to define this multipart response, and this
flow.sendMultiple() method.
The content of this response will actually be the same as what comed
back to the browser with CForms in Ajax mode: a list of <bu:replace
id="foo"> instructions, that the client-side JS places in the
appropriate locations.
Hope this is clearer.
Sylvain
[1]
http://scottraymond.net/articles/2005/12/01/real-world-rails-rjs-templates
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
[snip]
> Tell me your thoughts. Am I completely off-track, or do you also want to
> build this great new thing?
Well, I've always been against dynamic pipelines and content-aware
selection. But yes, I've changed my mind.
scripted sitemap, pull-driven events, dynamic pipelines, yes, it's time
for those.
Not sure I understand what you mean by flow.sendMultiple() though. can
you explain in more detail what you mean there?
--
Stefano.
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
>
> Now while I agree with a lot of what you are saying I'm not really sure
> it completely addresses all the issues. For example, while allowing
> folks to use any container they want might be a good thing it can also
> make it more difficult if that just becomes one more thing they have to
> learn about. Frankly, I'd just say to heck with it and use Spring. At
> this point I don't think we have to worry about radical changes or the
> community dying. Of course, it then makes more sense to leverage Spring
> WebFlow as I have in mind. And since Spring is such a popular framework
> it makes it much more palatable for manager types - especially those who
> think EJBs suck and Spring/Hibernate is the answer.
Exactly (it must be that being in the same state produces the same
thoughts at the same time, scary...)
>
> By the way - I'm not interested in Cocoon being sexy.
Amen - there are many examples of "sexy but useless in the real world"
our there...
> I'm interested in
> seeing its adoption rate increase, which is a very different thing.
>
> As to your sitemap changes, I think what you have in mind is right on.
> It wouldn't bother me if in 3.0 we have only javaflow and flowscript for
> those who want to "roll their own" and webflow for those who prefer a
> stateful flow.
>
> As for your comments on Ajax, I don't know if you read it but you should
> take a look at this entry from Carsten's blog
> http://www.osoco.org/archives/2005/10/index.html.
>
Now, Ajax *is* a cool and exiting technology. The interesting part is
that users have been told in the past years that "javascript is evil"
(it doesn't really matter that javascript by itself is not evil, but the
implementations make it a nice tool for the dark side) and now out of a
sudden, "javascript is wonderful" and "you can't use my site without
javascript". This is a really interesting social aspect.
Although Ajax is interesting, it comes with several problems. Developing
web applications gets much harder, testing gets more complicated and the
load on your severs changes dramatically - if you take all of this
together, it will be interesting to see, if ajax will be the future or
not. Perhaps it is, perhaps it will be replaced by something different,
who knows. So what does this mean to us? Well, let's not focus too much
on this Ajax stuff, let's solve our real problems (and if we can add
some ajax support on the way, great).
Ah, and there is another thing: stable blocks. It is a nightmare, if
popular blocks heavily change between maintenance versions. There are
several projects out there, that skipped Cocoon - after using it for
some time - because they were totally fed up with adopting their code to
the newest Cocoon version. So a separate versioniong for blocks with
stable apis is a must. (I know, we already discussed this, but I think
this is the right place to just repeat it).
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
> The main point is to have container-independent code as much as
> possible. Providing multiple container integration may not be a goal
> per se, but should not be made impossible. The main point is that the
> pipeline API should be embeddable in other environments.
I have no problem with being container independent, but we should only
provide one implementation.
>>
>> By the way - I'm not interested in Cocoon being sexy. I'm interested
>> in seeing its adoption rate increase, which is a very different thing.
>
>
> You misunderstood what I said (or I used the wrong word). By "sexy" I
> mean appealing for users, because it makes things easy and fun. If
> that goal is achieved, adoption rate should increase. Being appealing
> for managers is a different thing as this more mean being either
> buzzword compliant or standards (at least defacto ones) compliant.
A Ferrari is sexy. But it is highly impractical for use in commuting to
and from work or in transporting goods. By saying a technology is sexy
it equates it in my mind with a Ferrari. It looks great but probably
doesn't fit really well with the work that needs to be done.
On the other hand, you have a product like IntelliJ Idea. I wouldn't
call it sexy. I'd call it smart. It may not have a really fancy GUI but
it sure makes me productive. Yes, we should be able to create sexy web
sites with Cocoon, but Cocoon itself doesn't have to be sexy - just smart.
>
>> As to your sitemap changes, I think what you have in mind is right
>> on. It wouldn't bother me if in 3.0 we have only javaflow and
>> flowscript for those who want to "roll their own" and webflow for
>> those who prefer a stateful flow.
>>
>> As for your comments on Ajax, I don't know if you read it but you
>> should take a look at this entry from Carsten's blog
>> http://www.osoco.org/archives/2005/10/index.html.
>
>
> Honestly, I think Ajax will radically change how we consider portals,
> not only technically in the way they are implemented, but by the
> relation users will have with the portal. Just have a look at
> http://www.google.com/ig to see what I mean.
It's a nice site, but it clearly isn't a portal. Clicking on links
causes you to leave the website, which a portal usually wouldn't do. But
this discussion really has nothing to do with making Cocoon better.
Ralph
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
<snip/>
> Now while I agree with a lot of what you are saying I'm not really
> sure it completely addresses all the issues. For example, while
> allowing folks to use any container they want might be a good thing it
> can also make it more difficult if that just becomes one more thing
> they have to learn about. Frankly, I'd just say to heck with it and
> use Spring.
The main point is to have container-independent code as much as
possible. Providing multiple container integration may not be a goal per
se, but should not be made impossible. The main point is that the
pipeline API should be embeddable in other environments.
> At this point I don't think we have to worry about radical changes or
> the community dying. Of course, it then makes more sense to leverage
> Spring WebFlow as I have in mind. And since Spring is such a popular
> framework it makes it much more palatable for manager types -
> especially those who think EJBs suck and Spring/Hibernate is the answer.
>
> By the way - I'm not interested in Cocoon being sexy. I'm interested
> in seeing its adoption rate increase, which is a very different thing.
You misunderstood what I said (or I used the wrong word). By "sexy" I
mean appealing for users, because it makes things easy and fun. If that
goal is achieved, adoption rate should increase. Being appealing for
managers is a different thing as this more mean being either buzzword
compliant or standards (at least defacto ones) compliant.
> As to your sitemap changes, I think what you have in mind is right
> on. It wouldn't bother me if in 3.0 we have only javaflow and
> flowscript for those who want to "roll their own" and webflow for
> those who prefer a stateful flow.
>
> As for your comments on Ajax, I don't know if you read it but you
> should take a look at this entry from Carsten's blog
> http://www.osoco.org/archives/2005/10/index.html.
Honestly, I think Ajax will radically change how we consider portals,
not only technically in the way they are implemented, but by the
relation users will have with the portal. Just have a look at
http://www.google.com/ig to see what I mean.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Ralph Goers <Ra...@dslextreme.com>.
OK. A few more comments. First, these are the strengths I see in Cocoon:
1. MVC2X. Although the term didn't originate here it certainly was
meant to apply to Cocoon. The separation of concerns is IMO
Cocoon's greatest strength and is the greatest weakness of many
other technologies. Unfortunately, we provide several features
that let you violate this.
2. XML - There is a lot of debate about the overuse of XML, but I
have found that it is a great way to take data obtained from
various sources for various purposes and to make it available to
web authors.
3. Flexibility - Source resolvers are a godsend. We are able to
things with Cocoon that would be almost impossible with other tools.
4. Capability - It comes with practically everything but the kitchen
sink.
And the weaknesses:
1. The user base in the U.S. is minisule. Selling management on
using Cocoon is practically impossible. Managers all seem to
follow the lemming syndrome - they force technology no matter how
bad it is because everyone else is using it. Unfortunately, there
is a logical rational for this - it is cheaper to hire engineers
and web developers for standard tools than it is to find ones who
know an offbeat technology. This leads right into
2. There are few, if any, third party tools available. Although you
can get XMLSpy or Oxygen are they really going to be a web
developer's best friend?
3. The learning curve. Way too much stuff to know. Because it
includes so much stuff it is often difficult to know the right way
to do something.
Now while I agree with a lot of what you are saying I'm not really sure
it completely addresses all the issues. For example, while allowing
folks to use any container they want might be a good thing it can also
make it more difficult if that just becomes one more thing they have to
learn about. Frankly, I'd just say to heck with it and use Spring. At
this point I don't think we have to worry about radical changes or the
community dying. Of course, it then makes more sense to leverage Spring
WebFlow as I have in mind. And since Spring is such a popular framework
it makes it much more palatable for manager types - especially those who
think EJBs suck and Spring/Hibernate is the answer.
By the way - I'm not interested in Cocoon being sexy. I'm interested in
seeing its adoption rate increase, which is a very different thing.
As to your sitemap changes, I think what you have in mind is right on.
It wouldn't bother me if in 3.0 we have only javaflow and flowscript for
those who want to "roll their own" and webflow for those who prefer a
stateful flow.
As for your comments on Ajax, I don't know if you read it but you should
take a look at this entry from Carsten's blog
http://www.osoco.org/archives/2005/10/index.html.
Ralph
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi,
On 2 Dec 2005, at 17:59, Sylvain Wallez wrote:
> My impression is that with all these changes, Cocoon will be sexy
> again. Add a bit of runtime analysis of databases and automatic
> generation of CForms to the picture, and you have something that
> has the same productivity as RoR, but in a J2EE environment.
This is the only bit I have a problem with so far ;-)
We need to do -far- more than your technical outline if we are to
compete with the likes of RoR. We need to focus on the user experience:
* explain -why- you'd use Cocoon (i.e. more detailed user requirement
descriptions of why you'd add the new features you outline would be a
massive step forward). A good friend of mine is constantly saying "I
don't understand why people would use Cocoon, I don't understand the
use-case for it". Maybe the framework's got too bloated and
obfuscated for people to understand the need for it?
* we need to make it easier to get up and running (I'm talking about
packaged distributions that run "out of the box" and Cocoon project
archetypes in m2). I'd also like to give a massive +1 to Carsten's
comments about needing tools, though I'd say there's no harm in
adding some magic in there as well for the people that don't want to
use the tools just yet.
* dare I say it, we need to make Cocoon not just sexy but also -fun-.
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Thomas Lutz <ma...@gmx.at>.
Irv Salisbury wrote:
<snip />
> 1. CForms - Our recent app has about 175 CForms. Each of the binding,
> definition, and template files were cocoon: URLs. For doing simple
> forms, having to write 3 files was a real pain and very time
> consuming. So, we started building our own meta file that contained
> enough information to generate all 3 files necessary on the fly. I am
> sure others have done so as well. It seems like for the simple cases
> (or even the medium cases) we should be able to get away with 1 or
> even 2 files that should have to be written. CForms is great, and
> making this easier to work with would be great.
So did I, basically it's just three pipelines testing wether a
"customized" file with binding/definition/template exists, and if not
generating them from a metadata xml with three xslt's...
Supplying such a basic "autogeneration" would be ok, but I think it's
important to keep the clean separation, as this is a very important
CForm feature.
I am not sure if I find enough time before christmas, but I was thinking
of providing a patch with three stylesheets, hibernate definition file
to CForm binding/template/definition... as this would be a starting
point for some sort of RoR like code generation tools, too.
<snip />
To answer the rest of your mail, Sylvain, I'll have to re-read and think
:-)... this will take some time...
regards,
tom
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Sylvain Wallez <sy...@apache.org>.
Irv Salisbury wrote:
> I realize I am not a committer or anything, but hopefully that doesn't
> prevent me from replying...
Sure. This the reason why development happens in public: everybody is
welcome and can voice his opinion.
> We have built a number of large cocoon based applications over the
> past 2.5 years. Everything you said in here is great, and I would
> love it if cocoon had it. I won't even comment on what you have
> written as I agreed with all of it.
>
> I would like to add a few more comments
>
> 1. CForms - Our recent app has about 175 CForms. Each of the binding,
> definition, and template files were cocoon: URLs. For doing simple
> forms, having to write 3 files was a real pain and very time
> consuming. So, we started building our own meta file that contained
> enough information to generate all 3 files necessary on the fly. I am
> sure others have done so as well. It seems like for the simple cases
> (or even the medium cases) we should be able to get away with 1 or
> even 2 files that should have to be written. CForms is great, and
> making this easier to work with would be great.
I wholeheartedly agree with you. CForms is powerful, but requires to
write reformulations of a single model in too many places. Domain model
(beans, xsd or sql schema), form, binding and to some extent template.
This a place where Rails and Django shine by enforcing the DRY principle
(Don't Repeat Yourself), even if we can consider they went too far in
the opposite direction.
I also used the approaches you mention (have you seen def2binding.xsl in
o.a.c.forms.resources?) and the recent SQL sample in CForms that uses
direct mapping of resultsets to forms is targeting in that direction too.
> 2. Memory usage. Now, maybe Stax helps with this, but I don't think
> so. With our latest app, which was pretty large, we had pipelines
> with many many steps in them. Often, these steps would be simple
> things that just change 1 or 2 elements in the XSL stream. When you
> are building a large cocoon app, you often needs lots of data flowing
> through the system. Each step in the pipeline generates sax events
> and memory garbage, even if you don't need it. To get around this, we
> wound up using XMLBeans and having Java objects "flowing" through the
> system that can be turned into XML on the fly. When you have a large
> cocoon app with lots of users, there is a lot more memory usage than
> other frameworks.
Yup.
> 3. More integration with XMLBeans (or JAXB). Going back and forth
> from JavaFlow to XML has benefits. (I agree with your earlier point
> that we shouldn't have to start with pipelines). XMLBeans (or JAXB)
> makes this a snap. It has the speed of SAX and the benefit that you
> can go back and forth between XML and Java easily. We made a lot of
> use of this in our recent app. It worked great. Downside is that you
> have to write an XML Schema for all XML interactions. (Which is also
> a good thing as it is then documented) I realize this wouldn't help
> the learning curve at all.
Interesting.
> 4. Java flow (or flowscript) as the ONLY pipeline language. Now, this
> may be too touchy, but if all requests entered into Javaflow or
> Flowscript, and then this was used as the "orchestration" language, I
> think that would be great. Make it so you can easily aggregate
> pipelines, do content based routing, etc. Pipelines then can be
> simpler and all logic is done in flowscript or Javaflow. You should
> be able to setup all your components in flow. Having this in Java or
> Javascript would make conditional processing much easier and removing
> the pipeline (as sacred as it is) would help us only have 1 language.
This is an idea that went through my head while writing the RT: move
away from the sitemap language and do everything with the pipeline API.
Now the declarative nature of the sitemap (even if it's actually a
programming language) makes it easy to have an overall view of how the
XML processing works. But the sitemap can also be the worst thing in the
world when many subpipelines and components with side effects are used!
> 5. Continuations. More needs to be understood about these. We found
> in our app that we spent a lot of time debugging how and when these
> are created, why they are created, and getting rid of them. It seems
> like for a simple Javaflow call, should we really create a
> continuation? If you don't ever do a sendPageAndWait, and simply use
> it as processing, why bother with the continuation? It is just
> something else that creates memory usage and something we have to
> worry about destroying.
>
> Cocoon is awesome and with AJAX and other XML technologies becoming
> more popular, it is slated to be THE framework to choose. I think you
> are very correct in that it won't be the way it is currently written.
Yep. There are some good concepts in Cocoon, but they are buried so deep
that people have hard times using them to their real power.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Ralph Goers <Ra...@dslextreme.com>.
Irv Salisbury wrote:
>
> 1. CForms - Our recent app has about 175 CForms. Each of the binding,
> definition, and template files were cocoon: URLs. For doing simple
> forms, having to write 3 files was a real pain and very time
> consuming. So, we started building our own meta file that contained
> enough information to generate all 3 files necessary on the fly. I am
> sure others have done so as well. It seems like for the simple cases
> (or even the medium cases) we should be able to get away with 1 or
> even 2 files that should have to be written. CForms is great, and
> making this easier to work with would be great.
So can you post what you have done to the wiki?
>
Re: [RT][long] Cocoon 3.0: the necessary mutation
Posted by Irv Salisbury <ir...@gmail.com>.
I realize I am not a committer or anything, but hopefully that doesn't
prevent me from replying...
We have built a number of large cocoon based applications over the
past 2.5years. Everything you said in here is great, and I would love
it if cocoon
had it. I won't even comment on what you have written as I agreed with all
of it.
I would like to add a few more comments
1. CForms - Our recent app has about 175 CForms. Each of the binding,
definition, and template files were cocoon: URLs. For doing simple forms,
having to write 3 files was a real pain and very time consuming. So, we
started building our own meta file that contained enough information to
generate all 3 files necessary on the fly. I am sure others have done so as
well. It seems like for the simple cases (or even the medium cases) we
should be able to get away with 1 or even 2 files that should have to be
written. CForms is great, and making this easier to work with would be
great.
2. Memory usage. Now, maybe Stax helps with this, but I don't think so.
With our latest app, which was pretty large, we had pipelines with many many
steps in them. Often, these steps would be simple things that just change 1
or 2 elements in the XSL stream. When you are building a large cocoon app,
you often needs lots of data flowing through the system. Each step in the
pipeline generates sax events and memory garbage, even if you don't need
it. To get around this, we wound up using XMLBeans and having Java objects
"flowing" through the system that can be turned into XML on the fly. When
you have a large cocoon app with lots of users, there is a lot more memory
usage than other frameworks.
3. More integration with XMLBeans (or JAXB). Going back and forth from
JavaFlow to XML has benefits. (I agree with your earlier point that we
shouldn't have to start with pipelines). XMLBeans (or JAXB) makes this a
snap. It has the speed of SAX and the benefit that you can go back and
forth between XML and Java easily. We made a lot of use of this in our
recent app. It worked great. Downside is that you have to write an XML
Schema for all XML interactions. (Which is also a good thing as it is then
documented) I realize this wouldn't help the learning curve at all.
4. Java flow (or flowscript) as the ONLY pipeline language. Now, this may
be too touchy, but if all requests entered into Javaflow or Flowscript, and
then this was used as the "orchestration" language, I think that would be
great. Make it so you can easily aggregate pipelines, do content based
routing, etc. Pipelines then can be simpler and all logic is done in
flowscript or Javaflow. You should be able to setup all your components in
flow. Having this in Java or Javascript would make conditional processing
much easier and removing the pipeline (as sacred as it is) would help us
only have 1 language.
5. Continuations. More needs to be understood about these. We found in our
app that we spent a lot of time debugging how and when these are created,
why they are created, and getting rid of them. It seems like for a simple
Javaflow call, should we really create a continuation? If you don't ever do
a sendPageAndWait, and simply use it as processing, why bother with the
continuation? It is just something else that creates memory usage and
something we have to worry about destroying.
Cocoon is awesome and with AJAX and other XML technologies becoming more
popular, it is slated to be THE framework to choose. I think you are very
correct in that it won't be the way it is currently written.
Thanks for listening.
Irv
On 12/2/05, Sylvain Wallez <sy...@apache.org> wrote:
>
> Hi all,
>
> For many years, I have been more than happy with Cocoon, enjoying the
> power and ease it brought for both publication and webapp projects. Over
> the last months however, other feelings have emerged: there are things
> that are definitely overly complex in Cocoon, and there have been some
> emerging frameworks leading to "wow, cool!" reactions rather than "yeah,
> yet another one". Also, I strongly believe that the Ajax revolution is
> quickly obsoleting the traditional reload-page-on-user-action model that
> prevailed on the web up to recently and requires frameworks that help
> building these new kinds of applications.
>
> All this to say that if we want Cocoon to have a bright future, it must
> go through a mutation. This RT dumps my current ideas about this,
> depicting something that IMO better fits today's needs while taking into
> account many years of innovation and what we learned from them.
>
> -- oOo --
>
> First of all, let's consider the place where Cocoon fits in the large
> family of webapp development frameworks.
>
> On one end, we have pure-J2EE things like Struts or JSF. They lead to
> writing a lot of Java classes, lots of XML config files, and try/fail
> cycles require compile/deploy/restart, even if some tools ease the task.
> Despite their heavyweight development process, they are widely accepted
> in large companies, both because the J2EE stamp pleases managers and
> because of the vast number of entreprise-grade libraries available.
>
> On the other end, we have scripted frameworks like Ruby on Rails,
> Django[1], etc. The try/fail cycle is basically save/reload, and writing
> simple stuff is very fast because of the use of convention over
> configuration and runtime generation of data models (e.g. through
> database introspection). Now recent comments[2] show that going beyond
> the basic stuff may not be that easy.
>
> Cocoon actually sits in the middle of this spectrum:
> - it's a Java servlet and can therefore use almost anything that's
> written in Java. The contents of our blocks show this well! As such it
> is somehow J2EE compliant and can be deployed in large companies, even
> if we have to convince managers that it's better than Struts.
> - it's a scripted framework: sitemap, XSL, templates, flowscript. Save
> and reload! And this goes further in 2.2 with auto reloading and
> compiling classloaders.
>
> So theoretically, Cocoon could be the "RoR of J2EE". Now in its current
> incarnation it won't. The learning curve is too steep, some
> architectural choices imposed by Cocoon actually go in the way of
> developers with the new emerging development practices, and 5 years of
> legacy led to a rather confusing picture, with tons of legacy components
> and many inconsistencies.
>
> Now Cocoon has also introduced a number of super-cool features and
> innovations that definitely make sense, but in a more lightweight and
> consistent environment.
>
> So let's draw a picture of what could be Cocoon 3.0. I use a major
> version as the ideas outlined below are more than likely to require a
> code base, even if many code snippets can be reused from the current code.
>
> -- oOo --
>
> Giving its real role to the controller
> --------------------------------------
>
> When we introduced flowscript, we decided that <map:pipeline> should be
> the central switchboard through which *all* request go, and introduced
> <map:call function>. This leads most webapps written in Cocoon to have
> their sitemap starting with something like:
>
> <map:match pattern="do_*">
> <map:call function="do_{1}"/>
> </map:match>
>
> Why in hell do we have to go through the sitemap to call a function and
> then go back to the sitemap through cocoon.sendPage()? This not only
> clutters up the sitemap with cut'n pasted snippets, but also makes the
> flowscript a second-zone citizen in the application.
>
> So I think we should change a bit the semantics of the sitemap and the
> priorities of its various components:
>
> - the sitemap is the configuration of the overall request processing of
> the application (or a subpart of it in the case of mounts). It defines
> the configuration of that request processing, which is composed of
> components (<map:components>), controllers (<map:flow>) and views
> (<map:pipeline>). And I even think these 3 parts should really be split
> in different files, i.e. moving components to a xconf and pipeline
> definitions to e.g. "pipelines.xml".
>
> - the processing flow in a sitemap goes *first* in the controller if
> there is one, and *second* in the view. Going to a <map:pipeline> to
> call back a function should really be an exceptional case, or even
> forbidden.
>
> - since it's no more called by the sitemap, the controller defines a
> single entry point, such as "process()". A builtin default
> implementation provides an equivalent to <map:call
> function="public_{request:sitemapURI}"/>, thus automatically publishing
> any public_xxx flowscript function. This is similar to
> HttpServlet.service() that calls doGet(), doPost(), etc depending on the
> HTTP method but still allows overloading service().
>
> - to allow sophisticated implementations of process() where needed, the
> matchers and selectors are made available to the controller, so that
> they can check the request environment as easily as the pipeline
> statements in sitemap.xmap (also have a look at the Django
> dispatcher[3]). This can allow to write something like:
>
> var match = cocoon.matchers.wildcard("admin/*");
> if (match) {
> if (authenticateAdmin()) {
> // call the function named by the '*'
> adminServices[match[1]]();
> } else {
> forbidden();
> }
> }
>
> - calling cocoon.sendPage(uri) directly goes to the <map:pipeline>
> section of the sitemap, to build a view. This seems obvious, but has an
> interesting side-effect: there is no more need to invent a private URL
> space such as "view-*" to have a two-step processing (controller/view)
> of the requests. We can even say that "cocoon.sendPage(null)" calls the
> sitemap with the current request URI untouched.
>
> Note: the controller examples in this RT are written in JavaScript, but
> JavaFlow should be considered on an equal ground, as Coocon's user base
> is two-sided, composed of people coming from the webdesign/php world,
> and others coming from the J2EE world. Also, JavaFlow should be the
> language of choice for builtin reusable helper controllers.
>
> -- oOo --
>
> Expression languages
> --------------------
>
> Do you know how many expression languages there are in Cocoon? Java,
> JavaScript, XPath, XReporter, JEXL, etc. There's also all the
> micro-languages defined by each of the input modules: many of them use
> XPath, but not all...
>
> Also, the way to access a given data is not the same in the sitemap
> (e.g. "{request-param:foo}") and in JXTG
> ("${cocoon.request.getParameter('foo')}" or even
> "#{$cocoon/request/parameters/foo}")
>
> We should restrict the number of languages to the useful minimum, and
> ensure they can be used consistently everywhere. This useful minimum
> looks to me as being JavaScript, XPath and Java (using Janino[4]).
>
> As for the syntax, I think we should use the simple "{..}" notation,
> with no initial character. To choose among the 3 expression languages,
> we have to choose a default one, and use prefixed expressions for the
> other ones. I consider JS to me the most versatile and thus to be the
> default language.
>
> That means we'll have "{cocoon.request.remoteHost}" or
> "{xpath:$cocoon/request/remoteHost}" or
> "{java:cocoon.getRequest().getRemoteHost()}".
>
> About XPath, I'm a bit skeptical wrt its actual usefullness with non-XML
> objects, which often looks weird. However, we need to be able to call
> XPath on DOM parts of a non-DOM data model, e.g.
> "{xpath(cocoon.session.attributes.userDoc, '/meta/dc:title')}". And
> interstingly this sample shows that a namespace prefix table must be
> available in the expression context for *all* languages.
>
> All this also means that we need a well-defined "cocoon" object defined
> identically in all contexts. Additional top-level objects can be
> available to provide context-specific data, such as "flow.sendPage()",
> "sitemap.resolve('../1')" or "template.consumer".
>
> -- oOo --
>
> Content-aware pipelines
> -----------------------
>
> Cocoon 1 had a DOM-based processing, meaning transformations could be
> chosen according to the pipeline content. Cocoon 2, when switching to
> SAX-based streamed pipelines, abandoned this ability. This hasn't been a
> real problem for a long time, as datasources were mostly passive
> documents of a well-known structure.
>
> Now things have changed a lot, and we have to deal with heterogeneous
> data types and content-driven processing. Let's take some real-life
> examples:
> - Content syndication: a feed's URL can provide RSS 0.9, 1.0, 2.0 or
> Atom. How can we decide what processing has to be applied on a feed if
> we don't know what's inside?
> - Forrest's infamous SourceTypeAction[5] identifies a document's type
> using pull parsing
> - SOAP requests: why is SOAP so badly integrated with Cocoon? We
> basically need to delegate to Axis that will then call a Java class. Why
> so? Because we're unable to choose the service to be called depending on
> the request's content.
> - finally, the ESB buzz is turning into real projects, and requires
> content-based routing of messages.
>
> There were some proposals to implement content-aware selectors[6] but
> they never materialized because of the impedance mismatch between a SAX
> stream and the usage of DOM (so Cocoon-1-ish!) that was proposed to
> implement them.
>
> Now Forrest's SourceTypeAction shows us the way: pull parsing.
>
> So let's switch pipelines from SAX push to StAX pull (JSR 173, see[7]).
> Content-aware matchers and selectors can then grab just the amount of
> information they need from the pipeline to make their decision. And
> contrarily to the SourceTypeAction that requires to resolve the source 2
> times (once for pull, once for push), the pipeline engine can
> transparently buffer the StAX events consumed by matchers and selectors
> to replay them in the next pipeline component.
>
> Using pull pipelines doesn't mean we have to trash everything.
> Converting DOM to/from StAX is straightforward, and so is StAX->SAX. The
> SAX->StAX conversion is less easy and requires either buffering or a
> separate thread.
>
> Using pull pipelines also has an interesting side effects on
> aggregations, as they can easily be inlined by pulling events
> successively from partial pipelines (i.e. without a serializer), e.g:
>
> <map:aggregate element="root">
> <map:part>
> <map:generate src="header.xml"/>
> <map:transform src="header2html.xsl"/>
> </map:part>
> <map:part src="content/{1}.xml"/>
> </map:aggregate>
> <map:transform src="layout.xsl"/>
> <map:serialize/>
>
> Actually, writing
>
> <map:part src="foo"/>
>
> is equivalent to writing
>
> <map:part>
> <map:generate type="file" src="foo"/>
> </map:part>
>
> -- oOo --
>
> Dynamic pipelines
> -----------------
>
> Yes, you read it well: dynamic pipelines. This is what comes next
> naturally after content-aware pipelines: with use cases like webservices
> and ESBs, the content-based routing is not enough and we also need
> controller-driven routing.
>
> For simpler cases, we already have cocoon.processPipelineTo() (and the
> more versatile PipelineUtils class), but having to call the sitemap and
> invent a private URL just to perform a transformation is really overkill.
>
> I'd like to be able to write the following in a flowscript:
>
> var pipeline = flow.newPipeline("non-caching");
> pipeline.setGenerator("stream");
> pipeline.addTransformer("xslt", "normalize.xsl");
> if (cocoon.matchers.xpath("/foo/bar[@id = '" +
> cocoon.session.attributes.bar_id + "']", pipeline)) {
> handleBar(pipeline);
> } else {
> wrongId();
> }
>
> What we can see above is that we don't even need a serializer for the
> pipeline to be useful, as we can pull events from it as soon as it has a
> generator. And that generator could well be another pipeline built
> somewhere else.
>
> Basically, the pipeline engine becomes a very general-purpose object
> that can be used not only in the sitemap (to build views), but also in
> the controller for content-driven business logic decisions.
>
> This programmatic building of pipelines can also be used by Cocoon
> components themselves to implement some built-in transformations, e.g.
> converting an XMLSchema to a CForms definition, without requiring to
> copy/paste the corresponding sitemap instructions in user sitemaps, of
> requiring to call a system-defined sitemap. IMO, the lack of reusable
> system pipelines is one of the reasons why there hasn't been many
> off-the-shelf products or applications built on top of Cocoon.
>
> Being able to directly use pipelines can also ease the integration of
> Cocoon as a transformation engine in other environments, such as an
> advanced message transformer in the ServiceMix ESB[8].
>
> -- oOo --
>
> Controller-driven responses
> ---------------------------
>
> The advent of Ajax applications leads to a radical change in web
> applications architectures. There are many requests that don't lead to
> producing a view, but sending data and/or control information. Having to
> call a pipeline for this is really useless and overkill, as we don't
> need any kind of processing.
>
> We therefore need the controller to be able to directly send a
> non-processed response. We already have an example of this in the Ajax
> stuff for CForms[9] to send a simple <bu:continue> when form interaction
> is finished and a full page reload is needed. Another example is data
> transmission with an Ajax client using JSON[10].
>
> So we need additional "sendxxx" methods in the controller: sendText(),
> sendObject(), sendBytes() and why not sendStream().
>
> Ajax applications also require aggregations defined at the controller
> level. Let's consider an Ajax shopping cart application: the page
> displays the items catalogue and a sidebar with the current content of
> the shopping cart. When the user browses the items, only the catalogue
> area needs to be refreshed on the page. When he adds an item to the
> cart, both areas need to be refreshed at once to show the updated cart.
> The knowledge of what parts of the page need to be refreshed is in the
> controller. A solution can be to call a pipeline that will generate an
> XInclude that itself will call other pipelines, but that's smelly and
> doesn't allow to give different view data to each of the pipelines.
>
> To allow this, we need something like:
> flow.sendMultiple(
> ["catalogue", { paginator: paginator }],
> ["cart-sidebar", { cart: cart }]
> );
>
> -- oOo --
>
> Core components
> ---------------------
>
> Moving to pull pipelines isn't the only important core change: we need
> to move away from Avalon for good. Now what container will we use? We
> don't care: Cocoon 3.0 will be written as POJOs, and will come with a
> "default" container. Will it be Spring, Hivemind, Pico? I don't know. We
> may even provide configurations for several containers, as does
> XFire[xxxxx].
>
> -- oOo --
>
> Ok, thanks reading so far.
>
> My impression is that with all these changes, Cocoon will be sexy again.
> Add a bit of runtime analysis of databases and automatic generation of
> CForms to the picture, and you have something that has the same
> productivity as RoR, but in a J2EE environment. It also includes what I
> learned when working on Ajax and the consequences it has on the overall
> system architecture.
>
> You certainly have noticed that the above is more about the controller
> than about the sitemap. This is because not much changes are needed
> there, except content-aware matchers and selectors. But a more featured
> controller will allow to trash a great number of pipeline components
> that were invented to circumvent controller limitations. The code base
> will shrink.
>
> There are also a number of simplifications that can be done by using
> builtin conventions over configuration, but I'll write about this later.
>
> Tell me your thoughts. Am I completely off-track, or do you also want to
> build this great new thing?
>
> Sylvain
>
> [1] www.djangoproject.com/
> [2] http://www.andrewsavory.com/blog/archives/000976.html
> [3] http://www.djangoproject.com/documentation/url_dispatch/
> [4] http://www.janino.net/
> [5]
>
> http://svn.apache.org/repos/asf/forrest/trunk/main/java/org/apache/forrest/sourcetype/SourceTypeAction.java
> [6] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101554683923592&w=2
> [7] http://stax.codehaus.org/
> [8] http://servicemix.codehaus.org/
> [9]
>
> http://svn.apache.org/repos/asf/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/flow/javascript/Form.js
> [10] http://bluxte.net/blog/2005-11/17-49-57.html
> [11] http://xfire.codehaus.org/
>
> --
> Sylvain Wallez Anyware Technologies
> http://bluxte.net http://www.anyware-tech.com
> Apache Software Foundation Member Research & Technology Director
>
>