GMime is an LGML mime parser written in C. It depends on glib, but glib is available on Windows: 32bit and 64bit (and all Unix-based platforms, including Mac OS X). It also creates inside visual studio afaict, so I don't see what the problem is. I know that at least one commercial Windows vendor sends libgmime.dll and libglib.dll to its product (Kerio Connect, iirc). Nokia even sends it to some of its phones.
Actually there is no such thing as a "light" Mime steam pair if you really expect it to do more than split the headers into ":" and does a random analysis of the Content-Type header to find the boundary line a then continue to process non-nested multisets (sort of useless outside of parsing HTTP responses and pre-configured mime messages that you control composition).
The reason parsers such as GMime are as large as the lines of code fit is because they are for developers who really want the correct and reliable processing and decoding of mime-part and headers. Look at my story about decoding rfc2047 tokens with a coded word for the idea of ​​how difficult it is to get (by the way, besides GMime and MimeKit, I still have to find open source mime parsers that can handle all the boundary cases discussed in my application).
Even with all this additional robust processing, it is still as fast or faster than most lightweight mime parsers, probably given that most of them use the readline approach. I saw that the “light” guys guys prefer to parse 25MB email files in 2-3 seconds and think it's “fast”. My unit tests for GMime parse 2 mbox files filled with messages larger than 1.2 GB (yes, gigabytes) in less time.
My point is that “light weight” is the criterion for crap by people who don’t know what they are talking about.
How about a judgment based on something meaningful, such as rfc compliance? Or a combination of rfc compliance and performance? In any case, GMime will be the winner in any meaningful comparison that you make.
jstedfast
source share