You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2004/03/05 16:26:54 UTC
[SUMMARY] From Woody to Cocoon Forms 1.0
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
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Posted by Stefano Mazzocchi <st...@apache.org>.
Tim Larson wrote:
> On Sat, Mar 06, 2004 at 07:05:01AM +0000, Tim Larson wrote:
>
>>On Fri, Mar 05, 2004 at 11:41:15PM +0000, 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 ;-)
>>
>><snip long, complex classloading/dependency discussion/>
>>
>>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.
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Posted by Tim Larson <ti...@keow.org>.
On Sat, Mar 06, 2004 at 07:05:01AM +0000, Tim Larson wrote:
> On Fri, Mar 05, 2004 at 11:41:15PM +0000, 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 ;-)
>
> <snip long, complex classloading/dependency discussion/>
>
> 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
Posted by Tim Larson <ti...@keow.org>.
On Fri, Mar 05, 2004 at 11:41:15PM +0000, 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 ;-)
<snip long, complex classloading/dependency discussion/>
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
Posted by Pier Fumagalli <pi...@betaversion.org>.
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 technical disadvantage into a social advantage. We
cannot guarantee cross-version compatibility for a particular set of
block, the community, if the block is "worthy" will make sure that it's
always up-to-date to the latest standards :-)
If you don't maintain your block, you're out :-) If you're not involved
with the community, your code will fade away :-) I wouldn't see this as
a problem! :-)
> This is the best answer I can give at the moment.
>
> Pier, anything to add here?
Yep... That I don't see versioning problems as a problem at all... If
we don't solve the versioning problem, we'll never have the other
problem of "uh, I don't know how that block works so I won't fix it or
update it" :-)
Pier
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Posted by Tim Larson <ti...@keow.org>.
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
Posted by Ugo Cei <u....@cbim.it>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Posted by Marc Portier <mp...@outerthought.org>.
Vadim Gritsenko wrote:
> Joerg Heinicke wrote:
>
>> Marc Portier <mpo <at> 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 Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
>Marc Portier <mpo <at> 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
Posted by Joerg Heinicke <jo...@gmx.de>.
Marc Portier <mpo <at> 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
Posted by Marc Portier <mp...@outerthought.org>.
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 Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Posted by Reinhard Pötz <re...@apache.org>.
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
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Posted by Steven Noels <st...@outerthought.org>.
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>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org