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