RE: [SUMMARY] From Woody to Cocoon Forms 1.0
Pier Fumagalli <[EMAIL PROTECTED]> writes: > > The way the JVM classloading mechanism is designed (well, the code > > verifier actually) is that you cannot have two classes with > the same > > name and package in the same classloading hierarchy. > > > > So, for example, suppose you have the following hierarchy: > > > > B > >/ > > A > >\ > > C > > > > where block A depends on block B and C. Now, if B and C expose the > > same class, there is no problem if that is accessed from B > or from C > > internally, but as soon as A starts to access it, which one does it > > get? > > Perfectly correct... More in details, A will have an instance of the > Class object from either B or C linked to the class name. For example > if both B and C expose the class "org.betaversion.MyClass", > the C and B > classloader will both contain an instance of that class > associated with > that name. > > When A receives an instance of "org.betaversion.MyClass" the ByteCode > Verifier will check it against A's classloader instance of the > "org.betaversion.MyClass" class object, which he got from either B or > C. > > If the instance of the class object A has is different from the one > that instantiated the object, well, the BCV will throw a > ClassCastException > > (It might be tricky to understand what's an instance of a Class and > what's an instance of an Object, if someone has some doubts, ask me, > please... I had to read the JVM specification 3 or 4 times before > grasping it) > > > So, in short, it is feasible (IMHO, even if I haven't tried yet) to > > come up with a classloading hierarchy that allows > isolation, but only > > when the semantics associated to the class usage are *really* > > isolated. > > It is absolutely possible, yes... IN THEORY! :-D > > It means that if (in the above example), we could analyze all classes > accessible by A supplied by B and C (which means all public classes), > analyze their signatures, come up with a list of all the class > instances which are "visible" from outside, we can safely see whether > we can (or not) satisfy our versions tree. > > In practice (though) this is quite impossible as 99.9% of the classes > created are always "public" and therefore accessible from the > children > class loaders... It's interesting to note that this same problem comes up on EJB related mailing lists from time to time. In particular, if you search the JBoss forums for "versioning" you'll note two things: 1) some EJB container vendors *may* have implemented versioning for EJB instances; 2) people want this feature and have proposed ways to do it that have at least partial buy in. Really, adding a version attribute to a JNDI lookup isn't a big deal. Extending a class loader to respect this attribute is a bit more of a pain, but is it that bad? I'd note that I'd differ from some proposals in that I'd default to oldest version instead of newest (since that makes it easier to keep old code running) if no version is specified. I've noted the similarities between some of the Cocoon block proposals and EJB management before. I'm beginning to suspect that if done right Cocoon blocks (and other Cocoon features) could replace EJB's for a lot of what we do with EJB's: eg, look up classes at run time, pull code out of remote repositories. Combined with Avalon pooling etc. and it's not clear what EJB's really buy you over blocks (we're not doing container managed persistence). > > Now, if A asks for a particular task that B executes, requiring > > version 1 of block X, then asks for another task, executed > by C, left > > to D, which handles to E which requires version 2 of X, > then you get a > > ClassCastException. No way out! > > > > And debugging this is going to be the biggest pain in the universe!! > > Not even debugging... Analyzing the dependencies (although possible) > will be a nightmare... > > > So, my suggestion is to create a dependency checker which will tell > > all the potential class collision conflicts, at deploy time (by > > crawling the class space, perform MD5 hashing of classes > and identify > > collisions) > > You don't even have to have an MD5 :-) Because even if you have the > SAME EXACT file, if that file is loaded by two different > classloaders, > you won't be able to do a cast operation... > > It's a matter of instances of class objects... The instance of the > class is different, no way you can cast... If you're working with EJB's it's likely you already have this problem (and it's not just casting). It's not unusual to have a data class loaded by the EJB container that is used in the servlet container. I spent a couple of hours just this week figuring out why adding a method to a data class suddenly resulted in a No Class Def Found; touching the class had resulted in Jikes building the classes in a different order and the EJB tree got an instance of the class that previously hadn't existed. In
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Tim Larson wrote: On Sat, Mar 06, 2004 at 07:05:01AM +, Tim Larson wrote: On Fri, Mar 05, 2004 at 11:41:15PM +, Pier Fumagalli wrote: On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote: Tim Larson wrote: On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote: Package: org.apache.cocoon.cforms here I would go "forms" instead. package naming is where the estate really is, where class collissions might happen. I understand how this seems like a good place for the battleground, but to introduce a new winner it looks like this would force us to break code compiled against the previous major version because we would be stealing the class and interface names for the new version. Does the new block system somehow solve this problem like via classloaders or something else? eh, very good question, actually. I spent a few hours discussing with Pier about this yesterday over IM. Pier, as usual, sees the very core problem and I always miss ;-) Ok, so to sum up the version/classloading discussion, this plan (using 'forms' for the package naming) involves burning the users on major version upgrade by for most practical purposes breaking the previous major forms version when introducing the new version. This is incorrect. You are breaking those people that want to use both versions in the same classloading context. The chance of this happening reduces the higher you get and forms are pretty high in the stack. I agree with the idea of forcing core developers to choose between adding enhancements incrementally versus making a *major* effort to prove that their new revolutionary version deserves to unseat the current framework, but making things tough for the users is going too far. I must be missing something, would somebody enlighten me? I talked with Antonio on IRC and he had a good idea (IMHO) for this. Make the package name start as either o.a.c.forms or o.a.c.forms1 and a new major version can go to o.a.c.forms2. This preserves the ONE-and-only current forms framework concept (identified by the current stable version number), while not introducing any classloading version problems. Also, the actual class names and interface names are not polluted with version numbers. WDYT? I don't think we need to go that far (this is hacky as hell). Don't worry, Tim, it's tricky but we are still in good shape :-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
On Sat, Mar 06, 2004 at 07:05:01AM +, Tim Larson wrote: > On Fri, Mar 05, 2004 at 11:41:15PM +, Pier Fumagalli wrote: > > On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote: > > >Tim Larson wrote: > > >>On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote: > > >>> Package: org.apache.cocoon.cforms > > >>> > > >>>here I would go "forms" instead. package naming is where the estate > > >>>really is, where class collissions might happen. > > >> > > >>I understand how this seems like a good place for the battleground, > > >>but to introduce a new winner it looks like this would force us to > > >>break code compiled against the previous major version because we > > >>would be stealing the class and interface names for the new version. > > >>Does the new block system somehow solve this problem like via > > >>classloaders or something else? > > > > > >eh, very good question, actually. I spent a few hours discussing with > > >Pier about this yesterday over IM. Pier, as usual, sees the very core > > >problem and I always miss ;-) > > > > Ok, so to sum up the version/classloading discussion, this plan > (using 'forms' for the package naming) involves burning the users > on major version upgrade by for most practical purposes breaking > the previous major forms version when introducing the new version. > > I agree with the idea of forcing core developers to choose between > adding enhancements incrementally versus making a *major* effort to > prove that their new revolutionary version deserves to unseat the > current framework, but making things tough for the users is going > too far. I must be missing something, would somebody enlighten me? I talked with Antonio on IRC and he had a good idea (IMHO) for this. Make the package name start as either o.a.c.forms or o.a.c.forms1 and a new major version can go to o.a.c.forms2. This preserves the ONE-and-only current forms framework concept (identified by the current stable version number), while not introducing any classloading version problems. Also, the actual class names and interface names are not polluted with version numbers. WDYT? --Tim Larson
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
On Fri, Mar 05, 2004 at 11:41:15PM +, Pier Fumagalli wrote: > On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote: > >Tim Larson wrote: > >>On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote: > >>> Package: org.apache.cocoon.cforms > >>> > >>>here I would go "forms" instead. package naming is where the estate > >>>really is, where class collissions might happen. > >> > >>I understand how this seems like a good place for the battleground, > >>but to introduce a new winner it looks like this would force us to > >>break code compiled against the previous major version because we > >>would be stealing the class and interface names for the new version. > >>Does the new block system somehow solve this problem like via > >>classloaders or something else? > > > >eh, very good question, actually. I spent a few hours discussing with > >Pier about this yesterday over IM. Pier, as usual, sees the very core > >problem and I always miss ;-) Ok, so to sum up the version/classloading discussion, this plan (using 'forms' for the package naming) involves burning the users on major version upgrade by for most practical purposes breaking the previous major forms version when introducing the new version. I agree with the idea of forcing core developers to choose between adding enhancements incrementally versus making a *major* effort to prove that their new revolutionary version deserves to unseat the current framework, but making things tough for the users is going too far. I must be missing something, would somebody enlighten me? --Tim Larson
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote: Tim Larson wrote: On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote: Package: org.apache.cocoon.cforms here I would go "forms" instead. package naming is where the estate really is, where class collissions might happen. I understand how this seems like a good place for the battleground, but to introduce a new winner it looks like this would force us to break code compiled against the previous major version because we would be stealing the class and interface names for the new version. Does the new block system somehow solve this problem like via classloaders or something else? eh, very good question, actually. I spent a few hours discussing with Pier about this yesterday over IM. Pier, as usual, sees the very core problem and I always miss ;-) Heh! :-) No, Ste, it's that I only have to shovel more crap than you have to on production environments... What it means is that I'd rather have a simpler (and more understandable) environment to code against, rather than a complete but complex one, because when shit happens, I'm going to be the one who has to bring our LIVE server up-and-running QUICK! :-P The way the JVM classloading mechanism is designed (well, the code verifier actually) is that you cannot have two classes with the same name and package in the same classloading hierarchy. So, for example, suppose you have the following hierarchy: B / A \ C where block A depends on block B and C. Now, if B and C expose the same class, there is no problem if that is accessed from B or from C internally, but as soon as A starts to access it, which one does it get? Perfectly correct... More in details, A will have an instance of the Class object from either B or C linked to the class name. For example if both B and C expose the class "org.betaversion.MyClass", the C and B classloader will both contain an instance of that class associated with that name. When A receives an instance of "org.betaversion.MyClass" the ByteCode Verifier will check it against A's classloader instance of the "org.betaversion.MyClass" class object, which he got from either B or C. If the instance of the class object A has is different from the one that instantiated the object, well, the BCV will throw a ClassCastException (It might be tricky to understand what's an instance of a Class and what's an instance of an Object, if someone has some doubts, ask me, please... I had to read the JVM specification 3 or 4 times before grasping it) So, in short, it is feasible (IMHO, even if I haven't tried yet) to come up with a classloading hierarchy that allows isolation, but only when the semantics associated to the class usage are *really* isolated. It is absolutely possible, yes... IN THEORY! :-D It means that if (in the above example), we could analyze all classes accessible by A supplied by B and C (which means all public classes), analyze their signatures, come up with a list of all the class instances which are "visible" from outside, we can safely see whether we can (or not) satisfy our versions tree. In practice (though) this is quite impossible as 99.9% of the classes created are always "public" and therefore accessible from the children class loaders... Note that this seems easy to enforce, but it's really not, especially if you get into block versioning!!! X.1 / B / A D \ / \ C E \ \ F X.2 Now, if A asks for a particular task that B executes, requiring version 1 of block X, then asks for another task, executed by C, left to D, which handles to E which requires version 2 of X, then you get a ClassCastException. No way out! And debugging this is going to be the biggest pain in the universe!! Not even debugging... Analyzing the dependancies (although possible) will be a nightmare... So, my suggestion is to create a dependency checker which will tell all the potential class collision conflicts, at deploy time (by crawling the class space, perform MD5 hashing of classes and identify collisions) You don't even have to have an MD5 :-) Because even if you have the SAME EXACT file, if that file is loaded by two different classloaders, you won't be able to do a cast operation... It's a matter of instances of class objects... The instance of the class is different, no way you can cast... So, in short: having to different versions of the same interface in memory is possible only if there is always a way for the system to differentiate between them. that is: no way to use them both. Trivial for a few blocks, but very tricky when the number of blocks dependencies explodes. Ok, I see that it MIGHT be a problem... But it will also be an incentive. If I (Pier) write a block, and that relies on a set of other blocks, and I CANNOT avoid the problem of "old versions", I will be forced to "maintain" my block if I want to use new features... It basically turns a tech
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Stefano Mazzocchi wrote: So, to sum up, here is my proposal: Block Title: Cocoon Forms +1 Block Name: cforms +0 (I would prefer just "forms" but "cforms" will do). Package: org.apache.cocoon.forms +1 Namespace: http://apache.org/cocoon/forms/definition/1.0 +1 Ugo
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Joerg Heinicke wrote: On 05.03.2004 19:49, Tim Larson wrote: Package: org.apache.cocoon.cforms here I would go "forms" instead. package naming is where the estate really is, where class collissions might happen. I understand how this seems like a good place for the battleground, but to introduce a new winner it looks like this would force us to break code compiled against the previous major version because we would be stealing the class and interface names for the new version. Does the new block system somehow solve this problem like via classloaders or something else? This was exactly the reason I liked the cforms in the package name more than just forms. BTW, why plural (c)forms instead of singular (c)form? NOTE: the name "cforms" or "forms" doesn't make any different in the previous versioning scenario. It's a completely unrelated problem and having a more distinctive name (cforms) is not going to help since the problem emerges violently already when you have two different versions of the same block installed in a single cocoon instance. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Tim Larson wrote: On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote: Package: org.apache.cocoon.cforms here I would go "forms" instead. package naming is where the estate really is, where class collissions might happen. I understand how this seems like a good place for the battleground, but to introduce a new winner it looks like this would force us to break code compiled against the previous major version because we would be stealing the class and interface names for the new version. Does the new block system somehow solve this problem like via classloaders or something else? eh, very good question, actually. I spent a few hours discussing with Pier about this yesterday over IM. Pier, as usual, sees the very core problem and I always miss ;-) The way the JVM classloading mechanism is designed (well, the code verifier actually) is that you cannot have two classes with the same name and package in the same classloading hierarchy. So, for example, suppose you have the following hierarchy: B / A \ C where block A depends on block B and C. Now, if B and C expose the same class, there is no problem if that is accessed from B or from C internally, but as soon as A starts to access it, which one does it get? So, in short, it is feasible (IMHO, even if I haven't tried yet) to come up with a classloading hierarchy that allows isolation, but only when the semantics associated to the class usage are *really* isolated. Note that this seems easy to enforce, but it's really not, especially if you get into block versioning!!! X.1 / B / A D \ / \ C E \ \ F X.2 Now, if A asks for a particular task that B executes, requiring version 1 of block X, then asks for another task, executed by C, left to D, which handles to E which requires version 2 of X, then you get a ClassCastException. No way out! And debugging this is going to be the biggest pain in the universe!! So, my suggestion is to create a dependency checker which will tell all the potential class collision conflicts, at deploy time (by crawling the class space, perform MD5 hashing of classes and identify collisions) So, in short: having to different versions of the same interface in memory is possible only if there is always a way for the system to differentiate between them. that is: no way to use them both. Trivial for a few blocks, but very tricky when the number of blocks dependencies explodes. This is the best answer I can give at the moment. Pier, anything to add here? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
On 05.03.2004 19:49, Tim Larson wrote: Package: org.apache.cocoon.cforms here I would go "forms" instead. package naming is where the estate really is, where class collissions might happen. I understand how this seems like a good place for the battleground, but to introduce a new winner it looks like this would force us to break code compiled against the previous major version because we would be stealing the class and interface names for the new version. Does the new block system somehow solve this problem like via classloaders or something else? This was exactly the reason I liked the cforms in the package name more than just forms. BTW, why plural (c)forms instead of singular (c)form? Joerg
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote: > Marc Portier wrote: > > >another argument for having [cforms] from my side was that you could > >never confuse it with the known english word 'form' that could mean an > >HTML form, a paper-form, a whatever formalism or whatnot... in > >discussions on these lists, and thus possibly introducing confusion that > >can be avoided > > I find myself selfdebating here. > > I'm 60% on forms "everywhere" and 40% on +1 the proposal. > > the reason for using "forms" everywhere is that I want people to fight > for having their features in, instead of going their own way with > another block. Understood, and I agree with the motivation. > Scratchpad blocks are awesome as a way to cover new ground and propose > new functionality, but once we start supporting them officially, well, > the things change. > > This is why the name change: > > - woody was a proposal > - Cocoon Forms are *the way* cocoon is going to handle forms from now on > > in a few years, there might be nothing left from woody in Cocoon Forms. > > Now, as I was explaining in IRC today, the scenario I want to avoid is > people coming up with, say "sforms" or "cform++" or "cform#" and branch off. > > This is my *only* concern. > > I would go "forms" all the way, in everything: namespaces and package > names... but Marc is right: "form" is too general as a term. We could do > it with sitemap or flowscript because they were descriptive yet special > enough. Forms clearly not descriptive enough. My main concern is about support and searching. 'Form' does not clarify which major version is being refered to so it could be hard to quickly find help for the right major version, since people are notorious for mentioning the package but not the version in their emails. > So, let's go over the proposal again: > > Block Title: Cocoon Forms, or Cocoon Forms 1.0 > > +1 for Cocoon Forms (no need to mention the version now) +1 As agreed previously. > Block Name: cforms > > +1, I would like forms better but we need to state cforms somewhere +1 cforms block solves the support/search issue mentioned above. > Package: org.apache.cocoon.cforms > > here I would go "forms" instead. package naming is where the estate > really is, where class collissions might happen. I understand how this seems like a good place for the battleground, but to introduce a new winner it looks like this would force us to break code compiled against the previous major version because we would be stealing the class and interface names for the new version. Does the new block system somehow solve this problem like via classloaders or something else? > Namespace: http://apache.org/cocoon/forms/definition/1.0 > > +1 +1 > NS Prefix: fd > > +0, doesn't really matter. +0 sounds fine, not much opinion. > So, to sum up, here is my proposal: > > > Block Title: Cocoon Forms > Block Name: cforms > Package: org.apache.cocoon.forms > Namespace: http://apache.org/cocoon/forms/definition/1.0 > > > -- > Stefano. --Tim Larson
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Marc Portier wrote: another argument for having [cforms] from my side was that you could never confuse it with the known english word 'form' that could mean an HTML form, a paper-form, a whatever formalism or whatnot... in discussions on these lists, and thus possibly introducing confusion that can be avoided I find myself selfdebating here. I'm 60% on forms "everywhere" and 40% on +1 the proposal. the reason for using "forms" everywhere is that I want people to fight for having their features in, instead of going their own way with another block. Scratchpad blocks are awesome as a way to cover new ground and propose new functionality, but once we start supporting them officially, well, the things change. This is why the name change: - woody was a proposal - Cocoon Forms are *the way* cocoon is going to handle forms from now on in a few years, there might be nothing left from woody in Cocoon Forms. Now, as I was explaining in IRC today, the scenario I want to avoid is people coming up with, say "sforms" or "cform++" or "cform#" and branch off. This is my *only* concern. I would go "forms" all the way, in everything: namespaces and package names... but Marc is right: "form" is too general as a term. We could do it with sitemap or flowscript because they were descriptive yet special enough. Forms clearly not descriptive enough. So, let's go over the proposal again: Block Title: Cocoon Forms, or Cocoon Forms 1.0 +1 for Cocoon Forms (no need to mention the version now) Block Name: cforms +1, I would like forms better but we need to state cforms somewhere Package: org.apache.cocoon.cforms here I would go "forms" instead. package naming is where the estate really is, where class collissions might happen. Namespace: http://apache.org/cocoon/forms/definition/1.0 +1 NS Prefix: fd +0, doesn't really matter. So, to sum up, here is my proposal: Block Title: Cocoon Forms Block Name: cforms Package: org.apache.cocoon.forms Namespace: http://apache.org/cocoon/forms/definition/1.0 -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Geoff Howard wrote: [EMAIL PROTECTED] wrote: Don't know if my vote counts, just in case: +1 Helma Technically, the "vote" of a non-committer isn't binding, but your opinion (and anyone like you) is important and definitely "counts". Always feel free to pipe in. Geoff +1 I have been eagerly watching all morning :)
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Vadim Gritsenko wrote: Joerg Heinicke wrote: Marc Portier outerthought.org> writes: Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a little chat on IRC and agreed on the following: Block Title: Cocoon Forms, or Cocoon Forms 1.0 Block Name: cforms Package: org.apache.cocoon.cforms Namespace: http://apache.org/cocoon/forms/definition/1.0 sorry for missing the argumentation on keeping the 'forms' here, or is this a typo? AFAIU it this is by intention, no typo. It means the implementation of a new Yes, no typo. Cocoon Forms 1.0 is the one and only form framework for Cocoon at the moment. Thus namespace is ...cocoon/forms/.../1.0 Once we have new-kid-on-the-block replacement for the Cocoon Forms 1.0, it will be named Cocoon Forms 2.0 and have namespace .../cocoon/forms/.../2.0 thx for clarifying (btw: any takers for my other remark on the order of version-number and cforms-subdomain?) form framework can happen in a parallel block, but the namespace always points to *the* form framework. For a new framework accepted as replacement for Woody later on the namespace will just change to 2.0. +1 from me for the proposal (no IRC possible from here) Joerg Vadim -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Joerg Heinicke wrote: Marc Portier outerthought.org> writes: Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a little chat on IRC and agreed on the following: Block Title: Cocoon Forms, or Cocoon Forms 1.0 Block Name: cforms Package: org.apache.cocoon.cforms Namespace: http://apache.org/cocoon/forms/definition/1.0 sorry for missing the argumentation on keeping the 'forms' here, or is this a typo? AFAIU it this is by intention, no typo. It means the implementation of a new Yes, no typo. Cocoon Forms 1.0 is the one and only form framework for Cocoon at the moment. Thus namespace is ...cocoon/forms/.../1.0 Once we have new-kid-on-the-block replacement for the Cocoon Forms 1.0, it will be named Cocoon Forms 2.0 and have namespace .../cocoon/forms/.../2.0 form framework can happen in a parallel block, but the namespace always points to *the* form framework. For a new framework accepted as replacement for Woody later on the namespace will just change to 2.0. +1 from me for the proposal (no IRC possible from here) Joerg Vadim
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Marc Portier outerthought.org> writes: > >> Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a > >> little chat on IRC and agreed on the following: > >> > >> Block Title: Cocoon Forms, or Cocoon Forms 1.0 > >> Block Name: cforms > >> Package: org.apache.cocoon.cforms > >> Namespace: http://apache.org/cocoon/forms/definition/1.0 > > sorry for missing the argumentation on keeping the 'forms' here, or is > this a typo? AFAIU it this is by intention, no typo. It means the implementation of a new form framework can happen in a parallel block, but the namespace always points to *the* form framework. For a new framework accepted as replacement for Woody later on the namespace will just change to 2.0. +1 from me for the proposal (no IRC possible from here) Joerg
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
[EMAIL PROTECTED] wrote: Don't know if my vote counts, just in case: +1 Helma Technically, the "vote" of a non-committer isn't binding, but your opinion (and anyone like you) is important and definitely "counts". Always feel free to pipe in. Geoff
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Le Vendredi, 5 mars 2004, à 17:16 Europe/Zurich, [EMAIL PROTECTED] a écrit : Don't know if my vote counts, just in case: +1 Thanks! Only votes from committers are "officially" counted but we always appreciate input from everybody. -Bertrand
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Reinhard Pötz wrote: Vadim Gritsenko wrote: Reinhard Pötz wrote: Tim Larson wrote: ... +1 'cforms' instead of just 'forms' I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is obvious because it's within the Cocoon CVS. WDOT? Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a little chat on IRC and agreed on the following: Block Title: Cocoon Forms, or Cocoon Forms 1.0 Block Name: cforms Package: org.apache.cocoon.cforms Namespace: http://apache.org/cocoon/forms/definition/1.0 sorry for missing the argumentation on keeping the 'forms' here, or is this a typo? NS Prefix: fd and similar for binding and templating I presume? we might question if reordering the sub-domain and version-no is not more natural then: xmlns:fd=http://apache.org/cocoon/cforms/1.0/definition xmlns:fb=http://apache.org/cocoon/cforms/1.0/binding wdot? Title goes to documentation, samples, wiki, etc. Package name "cforms" and block name "cforms" will allow possibility of parallel development of the next generation "Cocoon Forms 2.0" (block name dforms ;-)), when/if it happens. Namespace suggests that Cocoon Forms 1.0 is one and only official forms framework. Namespace prefix "fd" stands for "forms definition". Do we have a consensus now? Please chime in on IRC (somebody will have to count votes then), or here :-) Vadim +1 from me! in prinipal +1 from me too, except for the small questions/clarifications above. (sorry, didn't get to irc today) maybe just adding arguments that might not be needed any more: another argument for having [cforms] from my side was that you could never confuse it with the known english word 'form' that could mean an HTML form, a paper-form, a whatever formalism or whatnot... in discussions on these lists, and thus possibly introducing confusion that can be avoided what I liked about 'woody' was that it meant what it meant in a not to be confused way (except for those damn aussies of course :-))... probably this very property was extended into a perception of having a '2nd brand within the cocoon brand' I think cforms can nicely remove 'the brand within brand' feeling for those that find it necessary, stepping into 'forms' would have been killing the unique-naming-property that was the original reason for looking for a name for it in the first place regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: [SUMMARY] From Woody to Cocoon Forms 1.0
Don't know if my vote counts, just in case: +1 Helma > -Original Message- > From: Steven Noels [mailto:[EMAIL PROTECTED] > Sent: Friday, 05 March 2004 17:01 > To: [EMAIL PROTECTED] > Subject: Re: [SUMMARY] From Woody to Cocoon Forms 1.0 > > > On 05 Mar 2004, at 16:26, Vadim Gritsenko wrote: > > > Do we have a consensus now? Please chime in on IRC > (somebody will have > > to count votes then), or here :-) > > +1 > > > -- > Steven Noelshttp://outerthought.org/ > Outerthought - Open Source Java & XMLAn Orixo Member > Read my weblog athttp://blogs.cocoondev.org/stevenn/ > stevenn at outerthought.orgstevenn at apache.org >
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
On 05 Mar 2004, at 16:26, Vadim Gritsenko wrote: Do we have a consensus now? Please chime in on IRC (somebody will have to count votes then), or here :-) +1 -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Vadim Gritsenko wrote: Reinhard Pötz wrote: Tim Larson wrote: ... +1 'cforms' instead of just 'forms' I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is obvious because it's within the Cocoon CVS. WDOT? Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a little chat on IRC and agreed on the following: Block Title: Cocoon Forms, or Cocoon Forms 1.0 Block Name: cforms Package: org.apache.cocoon.cforms Namespace: http://apache.org/cocoon/forms/definition/1.0 NS Prefix: fd Title goes to documentation, samples, wiki, etc. Package name "cforms" and block name "cforms" will allow possibility of parallel development of the next generation "Cocoon Forms 2.0" (block name dforms ;-)), when/if it happens. Namespace suggests that Cocoon Forms 1.0 is one and only official forms framework. Namespace prefix "fd" stands for "forms definition". Do we have a consensus now? Please chime in on IRC (somebody will have to count votes then), or here :-) Vadim +1 from me! -- Reinhard
