You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@apache.org> on 2008/08/04 08:01:57 UTC
A new name for Corona (take 2)
Ralph Goers wrote:
> Reinhard Pötz wrote:
>> Corona currently consists of 4 functional modules:
>> cocoon-corona-pipeline, cocoon-corona-sitemap,
>> cocoon-corona-controller and cocoon-corona-servlet. Using functional
>> names isn't an appropriate solution for our problem. This would lead
>> to a lot of confusion because we would get names that are already used
>> (cocoon-pipeline, cocoon-sitemap).
>>
>> I'm really tired of this. What's next?
> 1) Just use Corona. If Eclipse complains we will be forced to rename the
> project to something else. Then you will get to do this all again, but
> it will be worse since artifacts will probably have been released and
> people will wonder where the project went.
> 2) Dream up a new name.
> a) Find a descriptive name along the lines of what Henri suggested -
> i.e. one or two words that describe what the purpose of the subproject is.
> b) Choose another codename despite Henri's suggestion. Use the link
> to TESS to determine whether it is available to use. Bertrand suggested
> one (Weedle). It doesn't show up at TESS and it's use on Google seems to
> revolve completely around Pokemon. A couple of other names were also
> suggested that I haven't checked.
As I said before, I don't see any chance for a descriptive name that
doesn't (partly) collide with something already existing in the Cocoon
world.
Weedle sounds (and looks) cute but TBH I'm not happy with its Pokemon
origin.
So let's find some more suggestions:
Cocoon Chasse
~~~~~~~~~~~~~
Chasse or chassé is a dance step used in many dances in many variants,
all of them being triple-step patterns of gliding character, steps going
basically step-together-step (see http://en.wikipedia.org/wiki/Chasse)
I really like the analogy to our concepts of pipelines:
Pipeline ....................... Chasse
Component ...................... Step
Chasse is also used in many dances. In analogy this is also one of the
goals of Corona that was designed to support different objects that are
streamed (SAX events, STaX events, etc.).
TESS doesn't show any usuage of Chasse in the context of software or
electronics.
Cocoon Merenque
~~~~~~~~~~~~~~~
Merengue is a type of lively, joyful music and dance that comes from the
Dominican Republic[1]. It is popular in the Dominican Republic, and all
over Latin America. Merengue means whipped egg whites and sugar in
Spanish, similar to the English word meringue. It is unclear as to why
this name became the name of the music of the Dominican Republic. But,
perhaps, It can trace its meaning from the movement on the dance floor
that could remind one of an egg beater in action.
(http://en.wikipedia.org/wiki/Merenque)
Again, I like the possible analogy of a pipeline and a dance.
TESS doesn't show any usage of Merenque.
Both names sound good to me as German speaker and I don't know of any
irritating connotation.
What do people who speak other languages think about it?
My personal preference is Chasse because it slightly sounds better to
me, is shorter and starts with a "C".
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: A new name for Corona (take 2)
Posted by Alfred Nathaniel <an...@apache.org>.
On Mon, 2008-08-04 at 08:24 +0200, Reinhard Pötz wrote:
> Let's summarize the proposed names (alphabetical order):
>
> Cocoon Chasse
-1: Too carnivore; makes me think first of the French term "la chasse"
meaning "deer hunting" or "a dish of deer meat".
> Cocoon Merenque
+0: How would you pronounce that? "meren-kee" / "merenk" / "meren-keh"?
> Cocoon Morus
-1: Too puritan; makes me think of Thomas Morus; also too close to Moron
> Cocoon Weedle
-1: Too childish
> Any general comments? Any other suggestions?
Carrying on the association chain from Cocoon Silk:
Cocoon Satin
Cocoon Cotton
Cocoon Fabric
Cheers, Alfred.
Re: A new name for Corona (take 2)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Vadim Gritsenko wrote:
> On Aug 4, 2008, at 3:49 AM, Ralph Goers wrote:
>>
>> I've never really liked the word "pipeline" because I tend to think
>> of surfing when I hear it. That isn't altogether bad I suppose, but
>> it isn't altogether accurate either. I tend to think of what Cocoon
>> does more as a "pipetree" rather than a pipeline since it isn't
>> strictly a linear process and many branches can come into play. I'm
>> not suggesting that that is a good name, but something more
>> descriptive where the Cocoon implementation would be the classic
>> example might have more significance in the long run.
>
> Cocoon Tubes? Connect series of tubes and you get a pipeline!
>
> :-)
>
> Vadim
Totally Tubular!
http://www.inthe80s.com/glossary.shtml
Ralph
Re: A new name for Corona (take 2)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Aug 4, 2008, at 3:49 AM, Ralph Goers wrote:
>
> I've never really liked the word "pipeline" because I tend to think
> of surfing when I hear it. That isn't altogether bad I suppose, but
> it isn't altogether accurate either. I tend to think of what Cocoon
> does more as a "pipetree" rather than a pipeline since it isn't
> strictly a linear process and many branches can come into play. I'm
> not suggesting that that is a good name, but something more
> descriptive where the Cocoon implementation would be the classic
> example might have more significance in the long run.
Cocoon Tubes? Connect series of tubes and you get a pipeline!
:-)
Vadim
Re: A new name for Corona (take 2)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Pötz wrote:
> Ralph Goers wrote:
>> Reinhard Pötz wrote:
>>>
>>>
>>> Let's summarize the proposed names (alphabetical order):
>>>
>>> Cocoon Chasse
>>> Cocoon Merenque
>>> Cocoon Morus
>>> Cocoon Weedle
>>>
>>> Could others please check these names too?
>>>
>>> Any general comments? Any other suggestions?
>> I would agree except to suggest that perhaps the second should be
>> Cocoon Merengue. I would also suggest Cocoon Meringue and it doesn't
>> appear to have any significant conflicts that I could find.
>
> I would be fine with Cocoon Meringue too (although I slightly prefer
> the idea of using the name of a dance). Let's add it to the list!
>
I was looking at "pipeline" in wikipedia and found
http://www.reference.com/browse/wiki/Pipeline_%28software%29. I guess I
shouldn't have been too surprised to see Cocoon right in the middle of
the page. But it got me wondering. If what you are building is really
going to be the heart or kernel of Cocoon then picking a codename may
not do it justice.
I've never really liked the word "pipeline" because I tend to think of
surfing when I hear it. That isn't altogether bad I suppose, but it
isn't altogether accurate either. I tend to think of what Cocoon does
more as a "pipetree" rather than a pipeline since it isn't strictly a
linear process and many branches can come into play. I'm not suggesting
that that is a good name, but something more descriptive where the
Cocoon implementation would be the classic example might have more
significance in the long run.
Of course, I suppose with our many attempts at a "new" Cocoon, Cocoon
PipeDream might also be an appropriate name! ;-)
Ralph
Re: A new name for Corona (take 2)
Posted by Reinhard Pötz <re...@apache.org>.
Ralph Goers wrote:
> Reinhard Pötz wrote:
>>
>>
>> Let's summarize the proposed names (alphabetical order):
>>
>> Cocoon Chasse
>> Cocoon Merenque
>> Cocoon Morus
>> Cocoon Weedle
>>
>> Could others please check these names too?
>>
>> Any general comments? Any other suggestions?
> I would agree except to suggest that perhaps the second should be Cocoon
> Merengue. I would also suggest Cocoon Meringue and it doesn't appear to
> have any significant conflicts that I could find.
I would be fine with Cocoon Meringue too (although I slightly prefer the
idea of using the name of a dance). Let's add it to the list!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: A new name for Corona (take 2)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Pötz wrote:
>
>
> Let's summarize the proposed names (alphabetical order):
>
> Cocoon Chasse
> Cocoon Merenque
> Cocoon Morus
> Cocoon Weedle
>
> Could others please check these names too?
>
> Any general comments? Any other suggestions?
I would agree except to suggest that perhaps the second should be Cocoon
Merengue. I would also suggest Cocoon Meringue and it doesn't appear to
have any significant conflicts that I could find.
Ralph
Re: A new name for Corona (take 2)
Posted by Jeremy Quinn <je...@apache.org>.
Has anyone suggested PAPI (Pipeline API) ?
.... sorry have not been following the thread ....
regards Jeremy
On 4 Aug 2008, at 07:24, Reinhard Pötz wrote:
> Any general comments? Any other suggestions?
Re: A new name for Corona (take 2)
Posted by Reinhard Pötz <re...@apache.org>.
Daniel Fagerstrom wrote:
it's great to see you here again!
> Reinhard Pötz skrev:
>> Carsten Ziegeler wrote:
>>> Reinhard Pötz wrote:
>>>>> You guys have finally convinced me. Let's use 3.0.x for Corona,
>>>>> clearly state that it is alpha software on the website in the
>>>>> README.txt of each release artifact and see what's happening.
>>>>>
>>>>> Then we only need to find a package name that isn't used in trunk
>>>>> because Corona should run in parallel with Cocoon 2.2 without a
>>>>> problem (haven't tried it yet but at least in theory).
>>>>>
>>>>> The simplest solution would be keeping 'corona' as part of the
>>>>> package name (org.apache.cocoon.corona). IIRC Tomcat also kept the
>>>>> 'catalina' package names.
>>>>>
>>>>> Any other suggestions?
>>>>
>>>> I forgot to mention that we also have to find unique Maven artifact
>>>> IDs for the reasons explained above.
>>>>
>>> Great, I'm fine with using 3.0.x as well.
>>>
>>> For the package names and artifact ids, I'm not sure if we should
>>> keep corona inside.
>>
>> I would have been fine for package names since they are internal, but
>> not for artifactIds or groupIds.
>>
>>> I would prefer to simply use different functional package names. And
>>> if we use the package names as group ids, we're fine.
>>
>> org.apache.cocoon.corona:corona-pipeline:1.0.0 ->
>> org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
>>
>> org.apache.cocoon.corona:corona-sitemap:1.0.0 ->
>> org.apache.cocoon.sitemap.language.xml:cocoon-sitemap-language-xml:3.0.0
>>
>> org.apache.cocoon.corona:corona-controller:1.0.0 ->
>> org.apache.cocoon.controller:cocoon-controller:3.0.0
>>
>> org.apache.cocoon.corona:corona-servlet:1.0.0 ->
>> org.apache.cocoon.http.servlet:cocoon-http-servlet:3.0.0
>> any better ideas? (org.apache.cocoon.servlet is already in use)
>>
> First I agree with using 3.0.x. Second for the package names I don't see
> that it should be a problem to reuse package names from Cocoon 2.2. If
> we want to be able to use Cocoon with OSGi it is imortant that a package
> only is exported from one module (bundle). But the package structure in
> Cocoon 2.2 is so messed up so it is not possible to use Cocoon 2.2
> together with OSGi in any practical way anyway. So from an OSGi POV the
> only important thing is to make the package structure of "Cocoon 3.0"
> OSGi friendly. For coexistence between "Cocoon 3.0" blocks and Cocoon
> 2.2 it is enough if the classes are different.
Thanks for the reminder. I was too much influenced by thinking of OSGi.
I also believe you're right that it is very unlikely that Cocoon 2.2
will ever be migrated to OSGi.
> But do you really think it will be worthwhile to make it possible to use
> Cocoon 2.2 and 3.0 together?
yes, if you have a large Cocoon 2.2 application and you want to use
Cocoon 3.0 to provide RESTful services. Cocoon 3.0 will be optimized for
this use case.
> While it might be possible with not to much
> work for the Corona stuff, I guess it will start to be rather painfull
> once people start to upgrade some of our blocks to 3.0.
I haven't thought about this yet but you're probably right. I'd say that
we keep the door open and see if using 2.2 and 3.0 together is a valid
use case that happens in practice.
> Anyway I would suggest:
>
> org.apache.cocoon.corona:corona-sitemap:1.0.0 ->
> org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0
> The only class name conflict here is SitemapServlet maybe we could use
> XmlSitemapServlet instead.
>
> org.apache.cocoon.corona:corona-servlet:1.0.0 ->
> org.apache.cocoon.servlet:cocoon-servlet:3.0.0
> Here the only conflict (that I found) is SitemapParameters, what about
> SitemapParameterMap or maybe just Parameters?
thanks for your investigations. When I do the migration to the new
artifactId/groupId/package names, I will rename the two classes.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: A new name for Corona (take 2)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Pötz skrev:
> Carsten Ziegeler wrote:
>> Reinhard Pötz wrote:
>>>> You guys have finally convinced me. Let's use 3.0.x for Corona,
>>>> clearly state that it is alpha software on the website in the
>>>> README.txt of each release artifact and see what's happening.
>>>>
>>>> Then we only need to find a package name that isn't used in trunk
>>>> because Corona should run in parallel with Cocoon 2.2 without a
>>>> problem (haven't tried it yet but at least in theory).
>>>>
>>>> The simplest solution would be keeping 'corona' as part of the
>>>> package name (org.apache.cocoon.corona). IIRC Tomcat also kept the
>>>> 'catalina' package names.
>>>>
>>>> Any other suggestions?
>>>
>>> I forgot to mention that we also have to find unique Maven artifact
>>> IDs for the reasons explained above.
>>>
>> Great, I'm fine with using 3.0.x as well.
>>
>> For the package names and artifact ids, I'm not sure if we should
>> keep corona inside.
>
> I would have been fine for package names since they are internal, but
> not for artifactIds or groupIds.
>
>> I would prefer to simply use different functional package names. And
>> if we use the package names as group ids, we're fine.
>
> org.apache.cocoon.corona:corona-pipeline:1.0.0 ->
> org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
>
> org.apache.cocoon.corona:corona-sitemap:1.0.0 ->
> org.apache.cocoon.sitemap.language.xml:cocoon-sitemap-language-xml:3.0.0
>
> org.apache.cocoon.corona:corona-controller:1.0.0 ->
> org.apache.cocoon.controller:cocoon-controller:3.0.0
>
> org.apache.cocoon.corona:corona-servlet:1.0.0 ->
> org.apache.cocoon.http.servlet:cocoon-http-servlet:3.0.0
> any better ideas? (org.apache.cocoon.servlet is already in use)
>
First I agree with using 3.0.x. Second for the package names I don't see
that it should be a problem to reuse package names from Cocoon 2.2. If
we want to be able to use Cocoon with OSGi it is imortant that a package
only is exported from one module (bundle). But the package structure in
Cocoon 2.2 is so messed up so it is not possible to use Cocoon 2.2
together with OSGi in any practical way anyway. So from an OSGi POV the
only important thing is to make the package structure of "Cocoon 3.0"
OSGi friendly. For coexistence between "Cocoon 3.0" blocks and Cocoon
2.2 it is enough if the classes are different.
But do you really think it will be worthwhile to make it possible to use
Cocoon 2.2 and 3.0 together? While it might be possible with not to much
work for the Corona stuff, I guess it will start to be rather painfull
once people start to upgrade some of our blocks to 3.0.
Anyway I would suggest:
org.apache.cocoon.corona:corona-sitemap:1.0.0 ->
org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0
The only class name conflict here is SitemapServlet maybe we could use
XmlSitemapServlet instead.
org.apache.cocoon.corona:corona-servlet:1.0.0 ->
org.apache.cocoon.servlet:cocoon-servlet:3.0.0
Here the only conflict (that I found) is SitemapParameters, what about
SitemapParameterMap or maybe just Parameters?
/Daniel
Re: A new name for Corona (take 2)
Posted by Reinhard Pötz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Pötz wrote:
>>> You guys have finally convinced me. Let's use 3.0.x for Corona,
>>> clearly state that it is alpha software on the website in the
>>> README.txt of each release artifact and see what's happening.
>>>
>>> Then we only need to find a package name that isn't used in trunk
>>> because Corona should run in parallel with Cocoon 2.2 without a
>>> problem (haven't tried it yet but at least in theory).
>>>
>>> The simplest solution would be keeping 'corona' as part of the
>>> package name (org.apache.cocoon.corona). IIRC Tomcat also kept the
>>> 'catalina' package names.
>>>
>>> Any other suggestions?
>>
>> I forgot to mention that we also have to find unique Maven artifact
>> IDs for the reasons explained above.
>>
> Great, I'm fine with using 3.0.x as well.
>
> For the package names and artifact ids, I'm not sure if we should keep
> corona inside.
I would have been fine for package names since they are internal, but
not for artifactIds or groupIds.
> I would prefer to simply use different functional package
> names. And if we use the package names as group ids, we're fine.
org.apache.cocoon.corona:corona-pipeline:1.0.0 ->
org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0
org.apache.cocoon.corona:corona-sitemap:1.0.0 ->
org.apache.cocoon.sitemap.language.xml:cocoon-sitemap-language-xml:3.0.0
org.apache.cocoon.corona:corona-controller:1.0.0 ->
org.apache.cocoon.controller:cocoon-controller:3.0.0
org.apache.cocoon.corona:corona-servlet:1.0.0 ->
org.apache.cocoon.http.servlet:cocoon-http-servlet:3.0.0
any better ideas? (org.apache.cocoon.servlet is already in use)
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: A new name for Corona (take 2)
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Pötz wrote:
>> You guys have finally convinced me. Let's use 3.0.x for Corona,
>> clearly state that it is alpha software on the website in the
>> README.txt of each release artifact and see what's happening.
>>
>> Then we only need to find a package name that isn't used in trunk
>> because Corona should run in parallel with Cocoon 2.2 without a
>> problem (haven't tried it yet but at least in theory).
>>
>> The simplest solution would be keeping 'corona' as part of the package
>> name (org.apache.cocoon.corona). IIRC Tomcat also kept the 'catalina'
>> package names.
>>
>> Any other suggestions?
>
> I forgot to mention that we also have to find unique Maven artifact IDs
> for the reasons explained above.
>
Great, I'm fine with using 3.0.x as well.
For the package names and artifact ids, I'm not sure if we should keep
corona inside. I would prefer to simply use different functional package
names. And if we use the package names as group ids, we're fine.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: A new name for Corona (take 2)
Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:
> Vadim Gritsenko wrote:
>> On Aug 4, 2008, at 3:01 PM, Carsten Ziegeler wrote:
>>
>>> solprovider@apache.org wrote:
>>>> Pick a number that will never be production for the experimental
>>>> branch e.g. 2.7. Skip a few numbers in case trunk needs another minor
>>>> number (e.g. 2.3 and 2.4) and to avoid confusion that this branch is
>>>> not the immediate successor to 2.2. Do not use 2.9 in case a
>>>> non-Corona pre-release branch is needed before 3.0.
>>>> A number both distinguishes code compatibility and suggests the
>>>> position in history better than a code name such as x.
>>>> "cocoon-2.7-pipeline" is obviously not compatible with Cocoon-2.2 or
>>>> Cocoon-3.0. This also handles all possible futures:
>>>> - The number suggests that the code becomes obsolete after 3.0 is
>>>> released if the branch becomes 3.0 or is abandoned;
>>>> cocoon-x-pipeline-1.0 does not.
>>>> - The branch could become NewName-1.0 if the projects split.
>>>> The Lenya project did this twice:
>>>> - Production 1.2 branched to 1.4 for development of 2.0.
>>>> - An experimental branch based on 1.2 incompatible with 1.4 was
>>>> named 1.3.
>>>>
>>> This sounds to me as the most pragmatic and simplest solution.
>>>
>>> We could start with version 2.7
>>
>> Too complicated / confusing. I'd rather have us use 3.0, and if that
>> does not work out, we can skip that and start 4.0. It worked fine for
>> Tomcat, can work for us too.
>
> You guys have finally convinced me. Let's use 3.0.x for Corona, clearly
> state that it is alpha software on the website in the README.txt of each
> release artifact and see what's happening.
>
> Then we only need to find a package name that isn't used in trunk
> because Corona should run in parallel with Cocoon 2.2 without a problem
> (haven't tried it yet but at least in theory).
>
> The simplest solution would be keeping 'corona' as part of the package
> name (org.apache.cocoon.corona). IIRC Tomcat also kept the 'catalina'
> package names.
>
> Any other suggestions?
I forgot to mention that we also have to find unique Maven artifact IDs
for the reasons explained above.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: A new name for Corona (take 2)
Posted by Reinhard Pötz <re...@apache.org>.
Vadim Gritsenko wrote:
> On Aug 4, 2008, at 3:01 PM, Carsten Ziegeler wrote:
>
>> solprovider@apache.org wrote:
>>> Pick a number that will never be production for the experimental
>>> branch e.g. 2.7. Skip a few numbers in case trunk needs another minor
>>> number (e.g. 2.3 and 2.4) and to avoid confusion that this branch is
>>> not the immediate successor to 2.2. Do not use 2.9 in case a
>>> non-Corona pre-release branch is needed before 3.0.
>>> A number both distinguishes code compatibility and suggests the
>>> position in history better than a code name such as x.
>>> "cocoon-2.7-pipeline" is obviously not compatible with Cocoon-2.2 or
>>> Cocoon-3.0. This also handles all possible futures:
>>> - The number suggests that the code becomes obsolete after 3.0 is
>>> released if the branch becomes 3.0 or is abandoned;
>>> cocoon-x-pipeline-1.0 does not.
>>> - The branch could become NewName-1.0 if the projects split.
>>> The Lenya project did this twice:
>>> - Production 1.2 branched to 1.4 for development of 2.0.
>>> - An experimental branch based on 1.2 incompatible with 1.4 was named
>>> 1.3.
>>>
>> This sounds to me as the most pragmatic and simplest solution.
>>
>> We could start with version 2.7
>
> Too complicated / confusing. I'd rather have us use 3.0, and if that
> does not work out, we can skip that and start 4.0. It worked fine for
> Tomcat, can work for us too.
You guys have finally convinced me. Let's use 3.0.x for Corona, clearly
state that it is alpha software on the website in the README.txt of each
release artifact and see what's happening.
Then we only need to find a package name that isn't used in trunk
because Corona should run in parallel with Cocoon 2.2 without a problem
(haven't tried it yet but at least in theory).
The simplest solution would be keeping 'corona' as part of the package
name (org.apache.cocoon.corona). IIRC Tomcat also kept the 'catalina'
package names.
Any other suggestions?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: A new name for Corona (take 2)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Aug 4, 2008, at 3:01 PM, Carsten Ziegeler wrote:
> solprovider@apache.org wrote:
>> Pick a number that will never be production for the experimental
>> branch e.g. 2.7. Skip a few numbers in case trunk needs another
>> minor
>> number (e.g. 2.3 and 2.4) and to avoid confusion that this branch is
>> not the immediate successor to 2.2. Do not use 2.9 in case a
>> non-Corona pre-release branch is needed before 3.0.
>> A number both distinguishes code compatibility and suggests the
>> position in history better than a code name such as x.
>> "cocoon-2.7-pipeline" is obviously not compatible with Cocoon-2.2 or
>> Cocoon-3.0. This also handles all possible futures:
>> - The number suggests that the code becomes obsolete after 3.0 is
>> released if the branch becomes 3.0 or is abandoned;
>> cocoon-x-pipeline-1.0 does not.
>> - The branch could become NewName-1.0 if the projects split.
>> The Lenya project did this twice:
>> - Production 1.2 branched to 1.4 for development of 2.0.
>> - An experimental branch based on 1.2 incompatible with 1.4 was
>> named 1.3.
>>
> This sounds to me as the most pragmatic and simplest solution.
>
> We could start with version 2.7
Too complicated / confusing. I'd rather have us use 3.0, and if that
does not work out, we can skip that and start 4.0. It worked fine for
Tomcat, can work for us too.
Vadim
Re: A new name for Corona (take 2)
Posted by Carsten Ziegeler <cz...@apache.org>.
solprovider@apache.org wrote:
> Pick a number that will never be production for the experimental
> branch e.g. 2.7. Skip a few numbers in case trunk needs another minor
> number (e.g. 2.3 and 2.4) and to avoid confusion that this branch is
> not the immediate successor to 2.2. Do not use 2.9 in case a
> non-Corona pre-release branch is needed before 3.0.
>
> A number both distinguishes code compatibility and suggests the
> position in history better than a code name such as x.
> "cocoon-2.7-pipeline" is obviously not compatible with Cocoon-2.2 or
> Cocoon-3.0. This also handles all possible futures:
> - The number suggests that the code becomes obsolete after 3.0 is
> released if the branch becomes 3.0 or is abandoned;
> cocoon-x-pipeline-1.0 does not.
> - The branch could become NewName-1.0 if the projects split.
>
> The Lenya project did this twice:
> - Production 1.2 branched to 1.4 for development of 2.0.
> - An experimental branch based on 1.2 incompatible with 1.4 was named 1.3.
>
This sounds to me as the most pragmatic and simplest solution.
We could start with version 2.7
+1
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: A new name for Corona (take 2)
Posted by so...@apache.org.
Pick a number that will never be production for the experimental
branch e.g. 2.7. Skip a few numbers in case trunk needs another minor
number (e.g. 2.3 and 2.4) and to avoid confusion that this branch is
not the immediate successor to 2.2. Do not use 2.9 in case a
non-Corona pre-release branch is needed before 3.0.
A number both distinguishes code compatibility and suggests the
position in history better than a code name such as x.
"cocoon-2.7-pipeline" is obviously not compatible with Cocoon-2.2 or
Cocoon-3.0. This also handles all possible futures:
- The number suggests that the code becomes obsolete after 3.0 is
released if the branch becomes 3.0 or is abandoned;
cocoon-x-pipeline-1.0 does not.
- The branch could become NewName-1.0 if the projects split.
The Lenya project did this twice:
- Production 1.2 branched to 1.4 for development of 2.0.
- An experimental branch based on 1.2 incompatible with 1.4 was named 1.3.
solprovider
On 8/4/08, Carsten Ziegeler <cz...@apache.org> wrote:
> Reinhard Pötz wrote:
> > Cocoon 2.2 already uses cocoon-pipeline-api-1.0.0,
> cocoon-sitemap-api-1.0.0., etc.
> Yes, I know - this complicates things a little bit.
>
> > What concrete name and version number should we use for what we call
> corona-pipeline now? cocoon-pipeline-1.0.0 or cocoon-pipeline-2.0.0 Or do
> you propose to split up corona-pipeline and corona-sitemap into
> api/impl/components like we did in trunk? (NB: I would vote -100 on this
> because it just doesn't make sense to split up things into api and impl
> modules when there is most probably no second implementation in sight.)
> >
> If there is no need to split,we shouldn't. I think the current corona stuff
> is a pipeline api so we should call it api :) Even if there are
> implementation classes in the package.
>
> > Don't you think that this will blur the lines between Cocoon trunk and the
> Corona code too much and make it really difficult to understand what modules
> can be used together?
> >
> Hmm, yes, perhaps - unfortunately we were not good when we introduced the
> current 2.2 module names.
>
> > Additionally we would carve it in stone that Corona becomes the next major
> version of Cocoon. Not that I'm against this in general, but I'm not sure if
> it isn't too early for such a decision.
> >
> Ok, we have several options: we could use 3.0.0 as version numbers, like
> pipeline-api-3.0.0 etc. This makes clear that this stuff is not usable with
> all the 2.x versions, but obviously this would create a strong perception of
> what would be a Cocoon 3.0.
>
> The other option I see is to use names that 2.2 is currently not using,
> like cocoon-pipe, but I don't think that this is a very clear distinguisher.
>
> Seigh, it's not that easy :( But on the other hand using a fantasy name
> doesn't really help either. If we have cocoon-pipeline-api-2.2 and
> corona-pipeline-api-1.0 it's as confusing.
>
> The corona stuff is an evolution of 2.2, so I think we should use
> functional names with version numbers 3.x and above. Hopefully this pays off
> in the long run.
> Carsten Ziegeler
Re: A new name for Corona (take 2)
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Pötz wrote:
>
> Cocoon 2.2 already uses cocoon-pipeline-api-1.0.0,
> cocoon-sitemap-api-1.0.0., etc.
>
Yes, I know - this complicates things a little bit.
> What concrete name and version number should we use for what we call
> corona-pipeline now? cocoon-pipeline-1.0.0 or cocoon-pipeline-2.0.0 Or
> do you propose to split up corona-pipeline and corona-sitemap into
> api/impl/components like we did in trunk? (NB: I would vote -100 on this
> because it just doesn't make sense to split up things into api and impl
> modules when there is most probably no second implementation in sight.)
If there is no need to split,we shouldn't. I think the current corona
stuff is a pipeline api so we should call it api :) Even if there are
implementation classes in the package.
> Don't you think that this will blur the lines between Cocoon trunk and
> the Corona code too much and make it really difficult to understand what
> modules can be used together?
Hmm, yes, perhaps - unfortunately we were not good when we introduced
the current 2.2 module names.
> Additionally we would carve it in stone that Corona becomes the next
> major version of Cocoon. Not that I'm against this in general, but I'm
> not sure if it isn't too early for such a decision.
Ok, we have several options: we could use 3.0.0 as version numbers, like
pipeline-api-3.0.0 etc. This makes clear that this stuff is not usable
with all the 2.x versions, but obviously this would create a strong
perception of what would be a Cocoon 3.0.
The other option I see is to use names that 2.2 is currently not using,
like cocoon-pipe, but I don't think that this is a very clear
distinguisher.
Seigh, it's not that easy :( But on the other hand using a fantasy name
doesn't really help either. If we have cocoon-pipeline-api-2.2 and
corona-pipeline-api-1.0 it's as confusing.
The corona stuff is an evolution of 2.2, so I think we should use
functional names with version numbers 3.x and above. Hopefully this pays
off in the long run.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: A new name for Corona (take 2)
Posted by Reinhard Pötz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Pötz wrote:
>>
>> What would Spring do if the have a rewrite that _might_ become Spring
>> 4.0 but they don't know yet?
>>
> Ok, I can't read their minds, but it's easier for them as they already
> have functional names, So a 4.0 for them is just re-using the right
> functional names, adding some, dropping others perhaps. (Just speculating)
Cocoon 2.2 already uses cocoon-pipeline-api-1.0.0,
cocoon-sitemap-api-1.0.0., etc.
What concrete name and version number should we use for what we call
corona-pipeline now? cocoon-pipeline-1.0.0 or cocoon-pipeline-2.0.0 Or
do you propose to split up corona-pipeline and corona-sitemap into
api/impl/components like we did in trunk? (NB: I would vote -100 on this
because it just doesn't make sense to split up things into api and impl
modules when there is most probably no second implementation in sight.)
>
>>> Atm we have only a small set of modules in the Corona code, but
>>> perhaps this might crow and the more it crows, the more difficult it
>>> will be to tell people what Corona is.
>>
>> Can you give an example for such descriptive names?
>>
>> I like the idea of functional names but I just fail to see how this
>> can work in our case :-/
>>
> One of them could be "Cocoon Pipeline API", "Cocoon Sitemap API" (I
> don't like this very much - but it's just an example).
Don't you think that this will blur the lines between Cocoon trunk and
the Corona code too much and make it really difficult to understand what
modules can be used together?
Additionally we would carve it in stone that Corona becomes the next
major version of Cocoon. Not that I'm against this in general, but I'm
not sure if it isn't too early for such a decision.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: A new name for Corona (take 2)
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Pötz wrote:
>
> What would Spring do if the have a rewrite that _might_ become Spring
> 4.0 but they don't know yet?
>
Ok, I can't read their minds, but it's easier for them as they already
have functional names, So a 4.0 for them is just re-using the right
functional names, adding some, dropping others perhaps. (Just speculating)
>> Atm we have only a small set of modules in the Corona code, but
>> perhaps this might crow and the more it crows, the more difficult it
>> will be to tell people what Corona is.
>
> Can you give an example for such descriptive names?
>
> I like the idea of functional names but I just fail to see how this can
> work in our case :-/
>
One of them could be "Cocoon Pipeline API", "Cocoon Sitemap API" (I
don't like this very much - but it's just an example).
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: A new name for Corona (take 2)
Posted by Reinhard Pötz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Pötz wrote:
>> I still think that we shouldn't use a descriptive name in order to not
>> confuse our users (and ourselves).
>
> The more I think about it, the more I come to the conclusion that we
> should use descriptive names :)
> The current Corona code is a collection of various modules that are
> developed in layers. I can use the lowest layer (the pipelines) without
> ever using the above layers (sitemap, controller etc.). So I end up with
> using a part of Corona. This part is (small) project on its own and imho
> calls for an own name.
> If we think further ahead, we might come to the point where we base
> Cocoon 3.0 on Corona - and I think at this point, it's easier if we have
> descriptive names - as a Cocoon 3.0 is just the assembly of the separate
> parts with some additional sugar on top (ok, this might sound easier as
> it might be in the end, but anyway).
>
> If you look at other projects, for instance Spring or Felix, they're
> doing it the same way: descriptive names.
What would Spring do if the have a rewrite that _might_ become Spring
4.0 but they don't know yet?
> Atm we have only a small set of modules in the Corona code, but perhaps
> this might crow and the more it crows, the more difficult it will be to
> tell people what Corona is.
Can you give an example for such descriptive names?
I like the idea of functional names but I just fail to see how this can
work in our case :-/
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: A new name for Corona (take 2)
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Pötz wrote:
> I still think that we shouldn't use a descriptive name in order to not
> confuse our users (and ourselves).
The more I think about it, the more I come to the conclusion that we
should use descriptive names :)
The current Corona code is a collection of various modules that are
developed in layers. I can use the lowest layer (the pipelines) without
ever using the above layers (sitemap, controller etc.). So I end up with
using a part of Corona. This part is (small) project on its own and imho
calls for an own name.
If we think further ahead, we might come to the point where we base
Cocoon 3.0 on Corona - and I think at this point, it's easier if we have
descriptive names - as a Cocoon 3.0 is just the assembly of the separate
parts with some additional sugar on top (ok, this might sound easier as
it might be in the end, but anyway).
If you look at other projects, for instance Spring or Felix, they're
doing it the same way: descriptive names.
Atm we have only a small set of modules in the Corona code, but perhaps
this might crow and the more it crows, the more difficult it will be to
tell people what Corona is.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: A new name for Corona (take 2)
Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:
> Ralph Goers wrote:
>> Reinhard Pötz wrote:
>>> Corona currently consists of 4 functional modules:
>>> cocoon-corona-pipeline, cocoon-corona-sitemap,
>>> cocoon-corona-controller and cocoon-corona-servlet. Using functional
>>> names isn't an appropriate solution for our problem. This would lead
>>> to a lot of confusion because we would get names that are already
>>> used (cocoon-pipeline, cocoon-sitemap).
>>>
>>> I'm really tired of this. What's next?
>> 1) Just use Corona. If Eclipse complains we will be forced to rename
>> the project to something else. Then you will get to do this all again,
>> but it will be worse since artifacts will probably have been released
>> and people will wonder where the project went.
>> 2) Dream up a new name.
>> a) Find a descriptive name along the lines of what Henri suggested
>> - i.e. one or two words that describe what the purpose of the
>> subproject is.
>> b) Choose another codename despite Henri's suggestion. Use the link
>> to TESS to determine whether it is available to use. Bertrand
>> suggested one (Weedle). It doesn't show up at TESS and it's use on
>> Google seems to revolve completely around Pokemon. A couple of other
>> names were also suggested that I haven't checked.
>
> As I said before, I don't see any chance for a descriptive name that
> doesn't (partly) collide with something already existing in the Cocoon
> world.
>
> Weedle sounds (and looks) cute but TBH I'm not happy with its Pokemon
> origin.
>
> So let's find some more suggestions:
>
> Cocoon Chasse
> ~~~~~~~~~~~~~
> Chasse or chassé is a dance step used in many dances in many variants,
> all of them being triple-step patterns of gliding character, steps going
> basically step-together-step (see http://en.wikipedia.org/wiki/Chasse)
>
> I really like the analogy to our concepts of pipelines:
>
> Pipeline ....................... Chasse
> Component ...................... Step
>
> Chasse is also used in many dances. In analogy this is also one of the
> goals of Corona that was designed to support different objects that are
> streamed (SAX events, STaX events, etc.).
>
> TESS doesn't show any usuage of Chasse in the context of software or
> electronics.
>
> Cocoon Merenque
> ~~~~~~~~~~~~~~~
> Merengue is a type of lively, joyful music and dance that comes from the
> Dominican Republic[1]. It is popular in the Dominican Republic, and all
> over Latin America. Merengue means whipped egg whites and sugar in
> Spanish, similar to the English word meringue. It is unclear as to why
> this name became the name of the music of the Dominican Republic. But,
> perhaps, It can trace its meaning from the movement on the dance floor
> that could remind one of an egg beater in action.
> (http://en.wikipedia.org/wiki/Merenque)
>
> Again, I like the possible analogy of a pipeline and a dance.
>
> TESS doesn't show any usage of Merenque.
>
>
> Both names sound good to me as German speaker and I don't know of any
> irritating connotation.
>
> What do people who speak other languages think about it?
>
>
> My personal preference is Chasse because it slightly sounds better to
> me, is shorter and starts with a "C".
>
We also got some suggestions on the users list:
Cocoon Recipe
~~~~~~~~~~~~~
(suggested by Daniel Bruessler)
"RECIPE" would be the mix of this:
RE(stful) C(ocoon) (p)IPE(line)
I haven't checked in detail if it is used together with software or
electronics but there are many hits on TESS.
Cocoon PUPA
~~~~~~~~~~~
(suggested by solprovider)
PUPA (always all capitals as an acronym) was the name of a software
project until 2002 when the project became GNU's Grub 2. Cocoon Pupa
is unlikely to be confused with an obsolete name for a pre-release
boot loader.
Checklist:
- Easily pronounceable in most languages. (Are there any modern
languages without the a P sound?)
- Negative cultural connotations? (The only American connotation
should not be negative for anybody over five years old.)
- Not currently used in software.
Barbara Slupik commented on this proposal: "Unfortunately this does not
sound good in Polish. It means bottom, on which you sit."
IMO this rules out this proposal.
Cocoon Pipes or Apache Pipes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(suggested by Hugh Sparks)
I still think that we shouldn't use a descriptive name in order to not
confuse our users (and ourselves).
Yahoo! published a product "Yahoo Pipes" last year. TESS also shows a
lot of hits for "pipe" in the context of software that I haven't checked
in detail.
Cocoon Morus
~~~~~~~~~~~~
(suggested by Mika Lehtonen)
1) it fits on the theme
2) Morus can be interpreted as 'More Us', referring to the community.
see http://en.wikipedia.org/wiki/Morus for details.
There are no hits on TESS.
Thanks again for all your proposals. I think the only name that could be
used is "Cocoon Morus".
- o -
Let's summarize the proposed names (alphabetical order):
Cocoon Chasse
Cocoon Merenque
Cocoon Morus
Cocoon Weedle
Could others please check these names too?
Any general comments? Any other suggestions?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: A new name for Corona (take 2)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Doing a quick Google I didn't find anything relevant on Merenque. For
Chasse I found http://www.atomicmpc.com.au/download/chasse.aspx and
http://www.chasseconsulting.com/. The first is some sort of
shareware/freeware hunting game for Windows and the second is a sales
consulting firm. I couldn't locate the website of the author of the
game, just various places it could be downloaded.
Personally, I don't think either of these names would be a problem and
would be happy with either one.
I kind of like Merengue. It makes me think of Lemon Meringue Pie :-) .
Meringue is also light and airly, sort of like a Cocoon. Did you notice
that when you typed in Merenque in wikipedia it changed the spelling to
Merengue? I didn't find anything relevant under that spelling on Google
or TESS either. dictionary.com doesn't have a listing for Merenque but
does for Merengue so I suspect that Merenque is an improper spelling in
English. Of course, that isn't necessarily a problem.
Ralph
Reinhard Pötz wrote:
> Ralph Goers wrote:
>> Reinhard Pötz wrote:
>>> Corona currently consists of 4 functional modules:
>>> cocoon-corona-pipeline, cocoon-corona-sitemap,
>>> cocoon-corona-controller and cocoon-corona-servlet. Using functional
>>> names isn't an appropriate solution for our problem. This would lead
>>> to a lot of confusion because we would get names that are already
>>> used (cocoon-pipeline, cocoon-sitemap).
>>>
>>> I'm really tired of this. What's next?
>> 1) Just use Corona. If Eclipse complains we will be forced to rename
>> the project to something else. Then you will get to do this all
>> again, but it will be worse since artifacts will probably have been
>> released and people will wonder where the project went.
>> 2) Dream up a new name.
>> a) Find a descriptive name along the lines of what Henri suggested
>> - i.e. one or two words that describe what the purpose of the
>> subproject is.
>> b) Choose another codename despite Henri's suggestion. Use the
>> link to TESS to determine whether it is available to use. Bertrand
>> suggested one (Weedle). It doesn't show up at TESS and it's use on
>> Google seems to revolve completely around Pokemon. A couple of other
>> names were also suggested that I haven't checked.
>
> As I said before, I don't see any chance for a descriptive name that
> doesn't (partly) collide with something already existing in the Cocoon
> world.
>
> Weedle sounds (and looks) cute but TBH I'm not happy with its Pokemon
> origin.
>
> So let's find some more suggestions:
>
> Cocoon Chasse
> ~~~~~~~~~~~~~
> Chasse or chassé is a dance step used in many dances in many variants,
> all of them being triple-step patterns of gliding character, steps
> going basically step-together-step (see
> http://en.wikipedia.org/wiki/Chasse)
>
> I really like the analogy to our concepts of pipelines:
>
> Pipeline ....................... Chasse
> Component ...................... Step
>
> Chasse is also used in many dances. In analogy this is also one of the
> goals of Corona that was designed to support different objects that
> are streamed (SAX events, STaX events, etc.).
>
> TESS doesn't show any usuage of Chasse in the context of software or
> electronics.
>
> Cocoon Merenque
> ~~~~~~~~~~~~~~~
> Merengue is a type of lively, joyful music and dance that comes from
> the Dominican Republic[1]. It is popular in the Dominican Republic,
> and all over Latin America. Merengue means whipped egg whites and
> sugar in Spanish, similar to the English word meringue. It is unclear
> as to why this name became the name of the music of the Dominican
> Republic. But, perhaps, It can trace its meaning from the movement on
> the dance floor that could remind one of an egg beater in action.
> (http://en.wikipedia.org/wiki/Merenque)
>
> Again, I like the possible analogy of a pipeline and a dance.
>
> TESS doesn't show any usage of Merenque.
>
>
> Both names sound good to me as German speaker and I don't know of any
> irritating connotation.
>
> What do people who speak other languages think about it?
>
>
> My personal preference is Chasse because it slightly sounds better to
> me, is shorter and starts with a "C".
>