james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [cycleclean] branch review and questions
Date Thu, 07 Jan 2010 14:32:06 GMT
Sounds like a bikeshed issue. Of all big changes what you don't like
are the 2 smaller changes :-)

>From your previous message where you talked about the fact that I
introduced big functional changes I thought there was much more than
this. These 2 are very minor changes that do not alter the way the
library is used by users nor any functional behaviour.

I'm sure that if the issues are only the 2 you list here we'll find a solution.

more inline,

2010/1/7 Oleg Kalnichevski <olegk@apache.org>:
> (1) Please revise / redo BasicMimeTokenStream / MimeTokenStream split or
> revert 895241. Consider making MimeTokenStream an interface as an
> option.

All I need is to have a dependency free token stream parser. If you
can suggest a better option that extracting the BaseMimeTokenStream
abstract class I'm fine with it. While I may like introducing an
interface, I fail to see how it fixes any issue here. Can you go in
details? (I don't understand why the abstract class hurts you so

> (2) Please make sure  LineReaderInputStream#unread() does not impose a
> particular mode of operation.

This is easy to change. I still think this is worse (performance and
memory wise) than the current solution. It is a really internal class
that should not be used by users and, in the last revision, it already
protects from multiple unread calls using exceptions. We use the
"unread" method in a single place of our code (furthermore this
already exists and works, other solutions should be implemented). If
we don't want to optimize it at the extreme maybe we can switch the
whole line reading behaviour to a Buffered Reader, so that we can
simply use mark/reset. But even mark/resent impose a particular mode
of operation. The fact is that we talk about buffers. If you don't
want to impose limits then you need infinite memory :-)


View raw message