Re: A new name for Corona (take 2)
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)
Vadim Gritsenko wrote:
On Aug 4, 2008, at 3:01 PM, Carsten Ziegeler wrote:
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
Reinhard Pötz wrote:
Vadim Gritsenko wrote:
On Aug 4, 2008, at 3:01 PM, Carsten Ziegeler wrote:
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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)
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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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
Re: A new name for Corona (take 2)
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.
Re: A new name for Corona (take 2)
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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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)
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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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)
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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
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 [EMAIL PROTECTED] 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)
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
On Aug 4, 2008, at 3:01 PM, Carsten Ziegeler wrote: [EMAIL PROTECTED] 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)
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)
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
