On 3/3/08, Remy Maucherat <[EMAIL PROTECTED]> wrote: > > On Mon, 2008-03-03 at 15:58 -0700, Filip Hanik - Dev Lists wrote: > > > Remy Maucherat wrote: > > > This problem is a small detail. Much more should be done if you want > to > > > do a refactoring: both the mark functionality and readLine need to > have > > > direct access to the buffer to be able to be coded in a sane way (and > be > > > more efficient too). > > > > > yes, so the question is for 6.0.x and 5.5.x, do we wanna proceed down > > the refactor route? > > I was against it in the beginning for the fear of regression. I > > personally think the whole bytechunk/charchunk thing is very complex, > > and can be done easier, but that is something I would play around in > > sandbox, and eventually bring into trunk if it was working. > > > I am not really interested in participating. Besides some possible > simple cleanup, CharChunk is actually too simple rather than too complex > (ByteChunk is just fine, and doesn't need additional features): to > improve, it would need to get mark capabilities and (unfortunately) get > a readLine (it's even more problematic to implement it outside the > class). I am pretty sure using the NIO buffers will be proposed for some > reason, which are horrible to use as far as I am concerned.
I think the byte->char conversion should be cleaned, the InputStream hack was needed 9 years ago because regular conversion sucked and we couldn't use the convertors directly. I've seen quite a few other projects doing the conversion themself at least for UTF8 and 8859-1. Regarding using NIO buffers - I agree with Remy, the flip()s are horrible, I think there is a version in sandbox that replaces byte[] with the ByteBuffers, and it doesn't seem to be worth it. However I think it would be just great to start making a distinction between 'buffer' and 'pointer to a buffer' - IMO that's the main cause of complexity. And maybe add 'implements CharSequence, Appendable' to make the coyote classes more friendly for direct use. > for 6.0.x and 5.5.x, I'd rather keep the fixes to the actual bug fix to > > maintain stability > > > There's no way this sort of work could be good for these branches. Since I'm quite out of sync - what is the current 'dev branch' and is there any 'some API changes allowed' release planned ? Costin Rémy > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
