Re: [GMime] More error information...

[Jeffrey Stedfast <jestedfa microsoft com>]

FWIW, 3.0 is the release for breaking API to make things better. So in general, I’m OK with breaking it.

Note: g_mime_stream_[file,fs]_new_for_path() have been renamed to _open() in 3.0 and as of now also take a 
GError.

In other exciting news, when GMime parses email addresses, it extracts the charset property in the rfc2047 
encoded-word token and sets that on the InternetAddress::charset field allowing you to both get access to it 
as well as override it when it gets written back out again.

Same now goes for GMimeParam as well (except that handles both rfc2047 encoded-word tokens as well as 
properly encoded rfc2231 blurbs).

GMimeParam now also has a GMimeParamEncodingMethod property which allows you to override the default and make 
it use rfc2047 encoding when writing out the headers instead of rfc2231.


Oh! Also… I was reading over your emails to the list and noticed that you recently replaced the SMTP backend. 
One of the problems you had was hiding various X-Balsa-* and Bcc headers?

So my solution to that in MimeKit was a FormatOptions class: 
http://www.mimekit.net/docs/html/T_MimeKit_FormatOptions.htm

Specifically, the HiddenHeaders property – a HashSet of header names to hide when writing out a message in 
the WriteTo() method:

http://www.mimekit.net/docs/html/M_MimeKit_MimeMessage_WriteTo.htm

I’ve been thinking of adding a GMimeFormatOptions to GMime. In fact, I was planning on implementing that this 
weekend…


Hope that helps,

Jeff


On 3/17/17, 2:02 PM, "Albrecht Dreß" <albrecht dress arcor de> wrote:

    Hi Jeff:
    
    Not sure if you have a wishlish for 3.0 and if it's still open...
    
    There are several function where it would be *really* helpful if they could pass extra error information, 
in particular the stream-related ones where fs errors can occur.  Example: for 
g_mime_stream_file_new_for_path(), it would be nice if it was
    
    GMimeStream *
    g_mime_stream_file_new_for_path (const char *path,
                                      const char *mode,
                                 GError **error);       // <------ !!
    
    like most other GLib functions (I today spent some time before I noticed the file I wanted to read with 
this function had bad permissions - the NULL response was not /that/ helpful!).
    
    Yes, this would change the API.  But the API changes anyway I guess, and there is a trivial upgrade path 
(just use NULL as error location) for existing applications.
    
    Thoughts?
    
    Cheers,
    Albrecht.