Re: [evolution-patches] patch for 24026 try harder to not send

[Suresh Chandrasekharan <Suresh Chandrasekharan Eng Sun COM>]

>rejected.

I expected this :)

>Thirdly, camel is multithreaded while gconf is not
>thread-safe. This is a Bad Thing (tm).

Hmmm....

>
>2. camel should not use evo-mail specific user data anyway (such as
>gconf keys or any other data that the mailer front-end saves
>independently of camel)

True when you see camel as an independent library, but when it's a part of 
Evolution...

I still know this is wrong, but want to fix this desperately.

>3. and most importantly... 
>
>-       return "UTF-8";
>+       return (camel_get_default_charset());
>
>that is just plain wrong and likely to cause data corruption. Do you
>understand why the code returns UTF-8 there? 
>

This may not be terribly wrong as you think, see that here the user defined 
encoding will be selected only if other detection mechanism do fail, so 
currently this will apply only for multibyte cases ( and undetected single byte 
cases, so there's no regression if the user does not set anything, output stills 
comes as UTF-8 ) , and if a japanese user sets the compose encoding to chinese 
and blames the data loss on Evolution she may as well deserve at least that 
much.

I'm not advocating anything here, but a knowledgeble user who wants her japanese 
mails to go out in iso-2022-jp so that it don't come up as junk in her 
receipients Outlook mail box unfortunately has to use some kind of fix like this 
for the time being...

Thanks,
Suresh