On Jan 9, 2008 4:41 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Niall Pemberton wrote: > > OK so now were down to agreeing the exception in IO-77 - once thats > > done I can cut an RC. > > > > I'm starting to think that with the javadoc.jar Notice/License issue I > > may cut the rc with m1, since m2 seems to painful ATM (I've spent far > > too much time battling with m2 recently). > > Problem solved in r610444: > https://svn.apache.org/viewvc?view=rev&revision=610444
Thanks - shouldn't we do this in commons-parent pom though, not just for IO? Niall > > Niall > > > > On Jan 9, 2008 9:24 AM, Henri Yandell <[EMAIL PROTECTED]> wrote: > >> Happy to move IO-137 over to post-1.4. > >> > >> Hen > >> > >> > >> On Jan 9, 2008 1:04 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > >>> OK looks like were nearly ready for IO 1.4 release - theres a minor > >>> issue to resolve on IO-77[1] so that just leaves IO-137[2] to decide > >>> whether we're going to do anything about for 1.4 or move it to > >>> post-1.4 - Henri and Jukka expressed interest on IO-137 - do you guys > >>> want to / have time to look at this? > >>> > >>> https://issues.apache.org/jira/browse/IO-77 > >>> https://issues.apache.org/jira/browse/IO-137 > >>> > >>> Niall > >>> > >>> > >>> On Jan 6, 2008 7:05 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > >>>> Hi, > >>>> > >>>> +1 to Commons IO 1.4! > >>>> > >>>> On Jan 6, 2008 4:58 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > >>>>> On Jan 6, 2008 2:23 AM, Henri Yandell <[EMAIL PROTECTED]> wrote: > >>>>>> I think we should deal with IO-137 as it's a minor enhancement and > >>>>>> comes with tests. I'll volunteer to look at that. > >>>>> I looked at this a while back and using the baos buffers directly in > >>>>> an InputStream raises a safety issue (if the baos is modified while > >>>>> the InputStream is being read) - do we care about that? > >>>> I kind of agree. I was thinking about proposing a "copy on write" flag > >>>> to reset() that would start with a new set of buffers when there are > >>>> InputStreams reading from the same buffers, but that seems too complex > >>>> to me. > >>>> > >>>> Apart from that, I like the general idea in IO-137 (it's similar to my > >>>> readFrom() proposal) so I'd like to see it in 1.4 if there's a > >>>> consensus on what form the feature should take. I'm willing to invest > >>>> some time to work out the details. > >>>> > >>>>>> IO-51 has tests, so worth a look at if that can be done before the > >>>>>> others are resolved. ie) punt to post-1.4 iff it's the last one left. > >>>>> I had a brief look and my initial thought was the Limiter should just > >>>>> be doing the throttling and the reading/writing should be in the > >>>>> input/output implementations - but I haven't looked in detail. > >>>> I looked at IO-51 a few months ago, and came to the same conclusion. > >>>> The implementation isn't too modular and probably too complex (i.e. > >>>> could be done with less code). Of course I didn't have time to come up > >>>> with an alternative implementation. > >>>> > >>>> I like the feature though, and I have some use cases where it would > >>>> come in handy, but I think it's better to improve the Limiter API > >>>> before the feature gets released. > >>>> > >>>>> IO-148 is done from my PoV - I left it open in case anyone wanted to > >>>>> object to me renaming it today. If Gary and Jukka are happy then we > >>>>> can mark it as fixed. > >>>> I'm happy. > >>>> > >>>> BR, > >>>> > >>>> Jukka Zitting > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Dennis Lundberg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
