commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [IO] Planning IO 1.4 release
Date Wed, 09 Jan 2008 21:39:13 GMT
On Jan 9, 2008 4:41 PM, Dennis Lundberg <dennisl@apache.org> 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 <flamefew@gmail.com> wrote:
> >> Happy to move IO-137 over to post-1.4.
> >>
> >> Hen
> >>
> >>
> >> On Jan 9, 2008 1:04 AM, Niall Pemberton <niall.pemberton@gmail.com> 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 <jukka.zitting@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> +1 to Commons IO 1.4!
> >>>>
> >>>> On Jan 6, 2008 4:58 AM, Niall Pemberton <niall.pemberton@gmail.com>
wrote:
> >>>>> On Jan 6, 2008 2:23 AM, Henri Yandell <flamefew@gmail.com>
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: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Dennis Lundberg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message