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