Sylvain.
On Fri, 2005-05-20 at 16:41 -0700, Jon Travis wrote:
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 >>> >>> >>> >> >> >> > > >
