I vetoed following options:
2.) optimization options as attributes of f:ajax
3.) optimization options within f:attributes nested in f:ajax
The reason for this is, f: is a spec namespace which we cannot
alter!
So f:ajax and options within f:ajax is out of the question!
This simply would break spec behavior and probably would be
prohibited by the TCK anyway!
In the past we relied on the t: namespace for such behavior
and I personally thing we should follow the way for future extensions as
well!
Werner
(
No I am not from the United Nations (although I would not mind to have a
UN salary ;-)
)
Ganesh schrieb:
Hi,
Vote was closed by 2009-04-27 09:55 a.m. Final results of the vote:
[1] +3, 1 veto
[2] +1, 3 vetoes
[3] +0, 3 vetoes
[4] +1, 0 vetoes
Thus, no consensus has been reached by this vote. This is, what the
decision making process on
http://apache.org/foundation/how-it-works.html#decision-making prescribes:
>>The rules require that a negative vote includes an alternative
proposal or a detailed explanation of the reasons for the negative vote.
The community then tries to gather consensus on an alternative proposal
that resolves the issue. In the great majority of cases, the concerns
leading to the negative vote can be addressed.
This process is called "consensus gathering" and we consider it a very
important indication of a healthy community.<<
So, as everybody has given alternative proposals, all vetoers are asked
to give detailed explanations for their negative votes to enable
consensus gathering. My personal observation is that everybody was
pretty fast with emitting vetoes making me feel I'm at the UNO security
council :-) Imho and though I can't emit a binding vote solutions [1] to
[3] all aren't that bad. Maybe everybody who emitted a veto could
consider weakening it to a +0 thus opening the path for a majority
decision?
Best Regards,
Ganesh
Ganesh schrieb:
> Hi,
>
> We are trying to agree on a way to include the optimization options
pps:true/false, queuesize:n, errorlevel:WARNING/ERROR/NONE for JSF 2.0
Javascript with the MyFaces JSF 2.0 implementation.
> We've got 4 different proposed solutions, each has been checked for
technical feasability:
>
> 1.) extra options packed in a new t:ajax tag and myfaces.ajax.request
> 2.) optimization options as attributes of f:ajax
> 3.) optimization options within f:attributes nested in f:ajax
> 4.) a separate taglibrary with a single tag mf:ajax included with the
core
> Please consider the solutions and vote! See previous mails on this
list with "f:ajax and MyFaces extensions" in the subject for further
details.
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes.
This is a code modification vote [1], so you can veto a solution with a
vote of -1. Please vote whole numbers. You can give a vote on each of
the 4 solutions. E.g. you can vote:
>
> 1.) +1
> 2.) +1
> 3.) +0
> 4.) -1
>
> The vote lasts for 72 hours. It start on 2009-04-24 9:55 a.m. and
ends on 2009-04-27 09:55 a.m.
>
> ------------------------------------------------
> [ ] +1 - you favourize this solution
> [ ] +0 - you don't like this solution
> [ ] -1 - you veto this solution
>
>
> Best Regards,
> Ganesh Jung
>
> [1] http://www.apache.org/foundation/voting.html
