2009/12/29 Oleg Kalnichevski <[email protected]>: > On Tue, 2009-12-29 at 11:31 +0100, Stefano Bagnara wrote: >> 2009/12/29 Oleg Kalnichevski <[email protected]>: >> > On Tue, 2009-12-29 at 00:51 +0100, Stefano Bagnara wrote: >> >> 2009/12/29 Robert Burrell Donkin <[email protected]>: >> >> > i'm worried that this kind of change will break IMAP and/or jsieve in >> >> > a way that's really hard to fix. this will really suck for james since >> >> > we'll have to fork a known good version of mime4j. if someone could >> >> > run the IMAP and JSieve build after any incompatible semantic change >> >> > then at least there'd be a chance that the regression would be >> >> > understood. >> >> >> >> Well, there was already changes wrt folding with MIME4J-141 so the >> >> compatibility issue was already open. >> > >> > I do not think so. Prior to MIME4J-146 only a copy of header body passed >> > to the parser was unfolded. The original header body was never mutated. >> >> What I mean is that DelegatingFieldParse.parse changed the behaviour >> with MIME4J-141 (previously it wasn't unfolding body, after it >> unfolded body). Whenever we change anything we can break things. IMO >> we should care about improving the current mime4j and if this means >> breaking some old code then the old code will need to be fixed/updated >> too. IMO jSieve doesn't care less of this stuff, while IMAP uses this >> only in message searching, and I would be that returning an unfolded >> body (like we do after MIME4J-146) FIXES a bug in searching strings in >> folded headers. >> >> BTW discussing whether this change introduce backward incompatibility >> or not is a waste of time. Changing things introduce backward >> incompatbilities. IMO the new behaviour is better than the old, and at >> least the new behaviour show consistency in what people is expected to >> get when they call Field.getBody (before mime4j-146 sometimes you got >> unfolded body, sometimes folded body.. for the same original header). >> > > Stefano, this is not about appointing the blame. However, just to get > things straight, prior to MIME4J-141 DelegatingFieldParse would simply > choke on folded values, plain and simple. So, MIME4J-141 fixed a > breakage without changing any existing behavior.
This depends on what is the intended usage of Parse. If we agree that "raw" is a folded byte sequence, and "body" is always an unfolded string then we should not have considered the previous behaviour a bug. We desperately need to add meaning to our methods. Let's define what is a field body (IMO an unfolded/decoded string representing the header) and make mime4j consistent in its usage. In my own view, MIME4J-141 added a workaround for a bug in RawField, as the parser (always IMO) was not expected to receive newlines in field values. >> If you think the change is bad I'll revert it. If you think there is a >> better solution, write about it. >> > > I am personally in favor of the change and would like to keep it. I > would even go as far as suggesting the field body value be trimmed as > well. We just need to make sure Robert's concerns are addressed. If the > only way to do so is by reverting the change, I am afraid this is what > we will have to do. I've investigated both jSieve and IMAP (and you can see I also tried to start tracking downstream users) and I really don't understand Robert's concerns. As I wrote previously this change, if anything, *FIXES* a possible issue in IMAP search. I guess he simply had no time to have a better look to the real patch and he's worried I'm randomly changing code ;-) I understand we agree that mime4j has consistency issues, interface issues, code organization issues. Let's start to fix some of them. If we talk so much about MIME4J-146 (nothing revolutionary, just a bugfix) then we won't move anywhere and we won't fix anything. If you *fear* my code ability I can work in branches, but I think history proved that branches are not good for this stuff. I bet that if I simply didn't mark the issue with "backward incompatibility" and instead I committed silently we wouldn't even be discussing ;-) ... 0.4, 0.5 and 0.6 introduced much bigger changes with less noise ;-) Stefano
