New to C2

["Lacerda, Wellington (AFIS)" <We...@fao.org>]

Hi,

I was developing a number of cocoon1 based apps and want know about C2:

-	As I saw, the main structural change is to turn it SAX oriented
(events).
-	In that model, a sitemap provides a description of a C2 process,
declaring its generators, transformers and serializers. These are meant to
replace the reactor model's producers, processors and formatters I believe.
-	In this new model, instead of supplying a Document or a Stream the
generator triggers events directly from its transformer and so on ? This was
what I understood from the code.
-	What is the intended schedule for C2 ?
-	What is the future of C1 ? Will it be a stable, production variant
(based on the reactor pattern etc), though frozen, something like Java 1.1
to Java 2/3 ?
-	What is the intended migration path from C1 to C2 ? (or is it
"forget about and start it over again") ?

Wellington Silva
UN/FAO - Rome 

C2: WML generation

[Matthew Langham <ml...@sundn.de>]

Hi,

Generating content for WAP devices (WML) does not yet seem possible with
C2 - what is the status?

Matthew Langham

--
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30   [mlangham@sundn.de - http://www.sundn.de]
=================================================================


------------------------------------------------------------------------------------------
...this mail was scanned for viruses by mailserver...

Re: New to C2

[Stefano Mazzocchi <st...@apache.org>]

"Lacerda, Wellington (AFIS)" wrote:
> 
> Hi,
> 
> I was developing a number of cocoon1 based apps and want know about C2:
> 
> -       As I saw, the main structural change is to turn it SAX oriented
> (events).

yep

> -       In that model, a sitemap provides a description of a C2 process,
> declaring its generators, transformers and serializers. These are meant to
> replace the reactor model's producers, processors and formatters I believe.

yes, we also have new names for them

 producer -> generator
 processor -> transformer
 formatter -> serializer

This name change reflects a need to structure design patterns in their
operation as well as a correct english naming for their actions and
wants to become the de-facto XML naming about such components.

> -       In this new model, instead of supplying a Document or a Stream the
> generator triggers events directly from its transformer and so on ? This was
> what I understood from the code.

Yes.

> -       What is the intended schedule for C2 ?

We hope to have a final implementation by the end of the year. A beta
version for end of October/early November.

> -       What is the future of C1?

C1 will remain supported and bugfixed until C2 is ready for primetime
and users are happy with it.

At this point, after a reasonable migration time (along with some
documentation on how to migrate and possibly helping tools), C1 will be
abandoned.

C2 will have *all* C1 functionalities, better performance, lighter
memory footprint and higher scalability, modularity, code clarity and
usability.

You'll find there will be no need to use C1 anymore.

> Will it be a stable, production variant
> (based on the reactor pattern etc), though frozen, something like Java 1.1
> to Java 2/3 ?

No, the reactor patter will be abandoned since it's considered harmful.

> -       What is the intended migration path from C1 to C2 ? (or is it
> "forget about and start it over again") ?

Of course not.

C2 is pre-alpha stage at this time and it's not a C1 replacement by far
in both terms of usability, functionality and stability.

Even if C2 is _NOT_ designed to make it easy for C1 users to migrate
(too many structural differences cannot allow this), the Cocoon dev team
will make the best effort to make it easier for everyone to migrate.

And I tell you the selfish reason for this: if users like C1 better,
then we'll be forced to update and manage "two" branches of the same
application, which is, in all possible senses, a project fork.

Project forks hurt the project, the development community and pollute
the project name. So we'll make the best effort for people to be able to
migrate to C2 with the least pain possible.

Of course, your mileage may vary, but the key point is that we want
_everybody_ to forget about C1, but we totally understand people
invested money in C1 and we respect this (so we'll support it until
everybody is confortable with C2 and has switched).

I don't care if this takes a week, a month or a year, the important
point is that this project must not fork and when you do clean-room
rewriting of a project, there is a great chance people might see this as
a fork and follow the old model.

Technologically speaking, this won't be the case (C1 sucks compared to
C2), but users need time and help to migrate and get confortable with
the new codebase, sitemap and all that.

But don't worry, as I said, it's our selfish goal to help users with the
migration as soon as possible to avoid effort duplication on two
codebases.

Hope this helps.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------