lexer, tokens, and content-types

[Matthias Andree]

On Mon, 09 Dec 2002, Scott Lenser wrote:

> I've been using libgmime and here's my opinions on it.  The interface is
> slightly complicated but very flexible.  The interface is actually very well
> designed and pretty intuitive.  The main problem with the interface is that
> while all the methods are well documented as to what types that take, sometimes
> the documentation is missing info on the intended way of doing things.  Some
> examples are included though mostly in the form of unit tests.  I have a version
> derived from bogofilter 0.7 using libgmime 1.90.6 which grabs everything except the
> content-encoding fields.  I haven't bothered to try to track down the getting
> access to the content-encoding field since it properly decodes it in all cases.
> The library seems to be under pretty active development and has good support
> for pretty much everything I could think you could want.  It supports a wide
> variety of RFCs and seems very interested in following the standards.  It
> has a _lot_ of features and is GPL'd.

How much ballast (that we don't need, like encoding) do we buy if we use
it? Can it be compiled as shared library?

> The following types of encoding are handled:
> 
> 7bit
> 8bit
> binary
> base64
> quoted printable

fine

> uuencode

we don't need that. test will not be uuencoded because it would be
unreadable for netscape then.

> Support for a large number of RFCs.  From the libgmime README:

Oh, well. No offense, but when I look at what RFC compliance qmail
claims and then violates (974, 1652), I'd rather not bet on those
claims.

We can probably wait for EPS 1.4 and see if it has matured by then.

>  * 0822: Standard for the Format of Arpa Internet Text Messages
>  * 1521: MIME (Multipurpose Internet Mail Extensions) Part One:
>          Mechanisms for Specifying and Describing the Format of 
>          Internet Message Bodies

These are outdated. 1521 is superseded by 2045ff. 822 is superseded by
2822.

>  * 2184: MIME Parameter Value and Encoded Word Extensions: Character
>          Sets, Languages, and Continuations

outdated, as written right below:

>  * 2231: MIME Parameter Value and Encoded Word Extensions: Character
>          Sets, Languages, and Continuations (Obsoletes rfc2184)

> Additional features:
> 
> error output redirection (uses glib for this, I don't know how it works
>   exactly)

We don't want libraries to clutter our output. I've seen dozens of cast
warnings from GTK+ applications, and from what you quoted, I fear we're
getting the same junk from gmime applications. I'm loathe to link _my_
software against libraries that write random junk to a random output
channel. For production versions, we want to redirect that junk to
/dev/null or prevent it from being printed unless the user requests
debug mode.

> parses from, to, etc lines into list of email addresses.  Parses the email
>   addresses into name sections and email address sections
> iconv integration.  Supports using iconv to convert character sets.  I
>   haven't looked at this much

The iconv part might be interesting; we don't need address parsing now
however.

Thanks for your having a look.

-- 
Matthias Andree