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: [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:51:13 GMT
2009/12/29 Oleg Kalnichevski <olegk@apache.org>:
> 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
>> >> > 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
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 ;-)


View raw message