Re: [Evolution-hackers] Review a patch?
I just attached 2 alternative patches - "the-hard-way.patch" is similar to your patch but should fix the long param value problem the second patch is simpler in that it simply quotes all the values even if the value doesn't need to be quoted. Jeff On Thu, 2008-05-22 at 04:17 -0400, Michael B. Trausch wrote: > On Wed, 2008-05-21 at 20:24 -0400, Jeffrey Stedfast wrote: > > Fudging the linked list in camel is a gross hack (made worse by the > > fact that the MIME specification does not dictate that the name param > > be last), this is why I suggested you do it in the composer by making > > it set the name parameter last when constructing the headers. > > My intention was simply to have the most potential code benefit from the > patch, as opposed to localizing a fix in a client of the library. The > real benefit to the patch is that it will prevent users from assuming > (rationally, even though incorrectly) that there is a problem with > _their_ client, since other clients happen to work. > > I would love to just see the right thing get fixed here; that would of > course be the ideal solution. However, most users wouldn't be able to > fix this issue, and they'd give up and go back to what they know---that > which they *perceive* to be functional. Of course, if it's fixed in > just the composer, that gets around the immediate issue, but what > happens if some other piece of code uses EDS to build a message to be > sent to a buggy server? Am I missing something? > > Thanks, > Mike > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Review a patch?
Did you try your patch with any really long file names? Jeff On Thu, 2008-05-22 at 04:17 -0400, Michael B. Trausch wrote: > On Wed, 2008-05-21 at 20:24 -0400, Jeffrey Stedfast wrote: > > Fudging the linked list in camel is a gross hack (made worse by the > > fact that the MIME specification does not dictate that the name param > > be last), this is why I suggested you do it in the composer by making > > it set the name parameter last when constructing the headers. > > My intention was simply to have the most potential code benefit from the > patch, as opposed to localizing a fix in a client of the library. The > real benefit to the patch is that it will prevent users from assuming > (rationally, even though incorrectly) that there is a problem with > _their_ client, since other clients happen to work. > > I would love to just see the right thing get fixed here; that would of > course be the ideal solution. However, most users wouldn't be able to > fix this issue, and they'd give up and go back to what they know---that > which they *perceive* to be functional. Of course, if it's fixed in > just the composer, that gets around the immediate issue, but what > happens if some other piece of code uses EDS to build a message to be > sent to a buggy server? Am I missing something? > > Thanks, > Mike > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Review a patch?
On Wed, 2008-05-21 at 20:24 -0400, Jeffrey Stedfast wrote: > Fudging the linked list in camel is a gross hack (made worse by the > fact that the MIME specification does not dictate that the name param > be last), this is why I suggested you do it in the composer by making > it set the name parameter last when constructing the headers. My intention was simply to have the most potential code benefit from the patch, as opposed to localizing a fix in a client of the library. The real benefit to the patch is that it will prevent users from assuming (rationally, even though incorrectly) that there is a problem with _their_ client, since other clients happen to work. I would love to just see the right thing get fixed here; that would of course be the ideal solution. However, most users wouldn't be able to fix this issue, and they'd give up and go back to what they know---that which they *perceive* to be functional. Of course, if it's fixed in just the composer, that gets around the immediate issue, but what happens if some other piece of code uses EDS to build a message to be sent to a buggy server? Am I missing something? Thanks, Mike -- Michael B. Trausch [EMAIL PROTECTED] home: 404-592-5746, 1 www.trausch.us cell: 678-522-7934 im: [EMAIL PROTECTED], jabber Ubuntu Unofficial Backports Project:http://backports.trausch.us/ signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Review a patch?
Fudging the linked list in camel is a gross hack (made worse by the fact that the MIME specification does not dictate that the name param be last), this is why I suggested you do it in the composer by making it set the name parameter last when constructing the headers. Jeff On Wed, 2008-05-21 at 17:50 -0400, Michael B. Trausch wrote: > Some time ago, I submitted a patch to fix a bug in Evolution [1,2] that > is a simple workaround for some types of broken servers that don't > properly parse MIME header fields. > > The patch was rejected, however, I (still) do not understand why, and I > would like to do so such that I can get this patch into Evolution. I > can understand that it's not fun to work around server issues, but the > fix is not bad, and it maintains MIME standards compliance, without any > side effects that I have been able to note. I have been using this > patch personally since before I submitted it. > > Any advice or ideas? > > Thanks! > Mike Trausch > > [1] http://tinyurl.com/4ltg99 (Launchpad) > [2] http://bugzilla.gnome.org/show_bug.cgi?id=518312 > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
