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 > >
