commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nicolas de loof" <nico...@apache.org>
Subject Re: [IO] Planning IO 1.4 release
Date Thu, 10 Jan 2008 13:54:01 GMT
I attached a new pacth to IO-77.

It implements Holger
Hoffstätte<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=h2o>suggestion
to use NIO for file copy - when a java
1.4 runtime is available - and relies on buffers on java 1.3.

Nico.

2008/1/9, Niall Pemberton <niall.pemberton@gmail.com>:
>
> 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).
>
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message