FWIW, this feature is very useful for us.

-- Jon


On May 11, 2005, at 8:14 AM, Martin Marinschek wrote:

Ok, I have started off...

- we can always get rid of the code again if it doesn't work out.

regards,

Martin

On 5/11/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:

 Thank you Sean.

I have no problem to improve/change this later on.
As far as I'm concerned, backward compatibility isn't very important yet
because our JSF applications are still relatively new and small.


 Sylvain.


On Wed, 2005-05-11 at 09:50 -0400, Sean Schofield wrote:
I agree with Kalle's sentiments that this is the nature of open source
software. Actually not just open source software, but any
collaborative effort. Building a consensus takes time but in the end,
the thorough discussion benefits everyone. While the feature is
relatively simple and our spare time is precious, this is something
that affects all of us. Not every new feature or component will fall
into this category. Tree2 took a lot longer with all of the debate,
but in the end it was better because I got some good ideas from
people.


In this case I think a vote is appropriate because there are some
strong reservations by some individuals and so Sylvain should have an
unambiguous answer as to how to proceed. We should also be willing to
change code after the fact if it results in an improvement.

So I say lets go ahead with Sylvain's approach now and lets take a
look at what he comes up with. If we come up with a better solution
or an improvement to the existing solution lets not limit ourselves
with concerns of backwards compatability.

So I will vote +1 for Sylvain's solution and reserve the right to
reopen the discussion later if we feel there are improvements to be
made.

sean


On 5/11/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:

Sean & Kalle,

I agree that this discussion helped to clarify some things, but I'm a

quite

worried by the time and efforts it takes to agree on such a small feature.
I don't underestimate the necessity of having a well thought API, but as
all of you, my time is spare, and I disagree that there is no harm in a
prolonged discussion.
If it's just too much effort to decide such issues, I should better do a
hack on my own, and forget about including it in Myfaces.


Please don't take this as an offense, it's just a general worry that this
would afraid others like me of contributing anything else than bug fixes.
I also dislike this voting process, but it is an attempt to keep this in a
reasonable time frame, so please try to make your mind, but don't ask for
another week of emails & extensive explanations.


As for the summary of the options, I agree with the one Martin just did
(thanks for your help by the way).


Sylvain.


On Tue, 2005-05-10 at 15:26 -0400, Sean Schofield wrote:

While discussing this has taken a long time, I don't see any wrong in
it. It's still cheap and easy compared to implementing different
components, then comparing their implementations, fixing possible bugs
etc.



I agree with Kalle that there is no harm in a prolonged discussion on
this. If memory serves me, we have only been discussing this for a
week or so. I think we should consider postponing the vote and taking
a little more time with this.


My reasoning is that this solves a problem that many of us (including
myself) need to have solved. Lets pick an approach that we can all
live with.


On the other hand, we owe it to Sylvain to not drag this out. Lets
try to resolve this quickly but also give it the consideration it
deserves. Also, the answer to this problem involves several "design
principles" that we should probably agree upon. For instance, concern
over bloated attributes, mutating components, etc.


I need some time to re-read this very extensive thread. Maybe Sylvain
or Kalle can summarize the options for us (Option #1, #2, etc.)
People can add new options (give them a new number) and we can have a
quick discussion and reference these options by # and discuss pros and
cons.



Kalle


sean













Reply via email to