lexer, tokens, and content-types

[David Relson]

At 07:47 PM 12/8/02, Matthias Andree wrote:

>Objection. EPS has some obvious bugs at first glance. We'd need to FULLY
>scrutinize EPS for RFC compliance first.
>
>I'd also tend to say "let's avoid copying data around", because that is
>what makes things slow. Let's try to get along with as few passes as
>possible.
>
> > So, in conclusion, I would suggest that we think about redesigning the
> > internal structure of bogofilter to allow for the use of an external
> > decoding library.
>
>That's what it boils down to one way or the other.

Matthias & Gyepi,

Looking at eps, I notice several things.

In content.h are #defined lots of content-types, content-transfer-encoding 
types, and content-disposition types.  In content.c are tables to convert 
types (as strings) to the defined names.  I also see files for converting 
mime and base64.  What I don't see are connections between the #defines and 
the code.  For example eps doesn't give us the connection from ENC_BASE64 
to base64.c.  It seems we must write our own "glue" code.  I don't see a 
#define for UUENCODE or code for processing other types they recognize, 
e.g. 7BIT, 8BIT, QP, or RAW.

There is a lot there, but eps isn't complete.  If we want completeness, we 
need to extend their package (perhaps a whole lot) or use another package.

David