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). If you think the change is bad I'll revert it. If you think there is a better solution, write about it. Stefano
