james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [jira] Resolved: (MIME4J-146) [possible backward incompatibility] Make sure "body" is always unfolded, "raw" is always folded, both in RawField and ParsedFields.
Date Tue, 29 Dec 2009 11:00:36 GMT
On Tue, 2009-12-29 at 11:31 +0100, Stefano Bagnara wrote:
> 2009/12/29 Oleg Kalnichevski <olegk@apache.org>:
> > On Tue, 2009-12-29 at 00:51 +0100, Stefano Bagnara wrote:
> >> 2009/12/29 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> >> > 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.

> 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.



> Stefano

View raw message