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 <[email protected]>: > (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 much..) > (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 :-) Stefano
