Re: [Evolution-hackers] Bug #232

[Peter Colijn <pcolijn nit ca>]

On Mon, 2003-11-17 at 13:44, Larry Ewing wrote: 
> A simple port probably wouldn't take very much time, but the problem is
> the way gtnef works is far less than ideal.  Because of licensing issues
> (the tnef code base it was derived from is GPL'd) it cannot be linked
> into the mailer so it has to be an exe component.  Since it has to be a
> component it has to duplicate a large amount of the mail display code to
> make an interface that looks similar to the normal attachment
> interface.  So it is both extremely slow to activate and annoying to
> maintain.

My company, Net Integration Technologies, is working on a plugin for
Evolution for its ExchangeIt Microsoft Exchange replacement technology.

As part of this plugin, we're writing a TNEF decoder/encoder, WvTnef. We
will probably be releasing it (and the plugin) soon as LGPL. It's
definitely clean-room, since I'm writing it, and I've never done
anything with TNEFs before in my life.

> In a perfect world camel would provide a plugable method for allowing a
> content type to present itself as a group of several other content-types
> so that the display code could be reused and someone would write an
> LGPL'D tnef decoder.  I can't write the tnef decoder myself since I've
> already messed with the current code a lot but if someone is serious
> about doing it we could probably clean room reverse engineer the GPL'd
> version.  I'll let one of the mail hackers comment on the plugable camel
> stuff.

For our plugin, we're more interested in the TNEF properties that are
used for calendar items, contacts, todo lists, etc. But we will also be
dealing with attachments (since in Outlook, you can have arbitrary
attachments on just about anything). The way the TNEF parser works now
is basically like a big hashtable. You tell it the MAPI id you want (or
the GUID + id or GUID + name string) and it gives it to you. I don't
know how suitable that would be to this particular purpose.

I just checked out ytnef, and it looks quite good, but (as far as I can
tell) it doesn't support all the MAPI properties; it seems designed to
handle primarily attachments (I'm sure the maintainer will correct me if
I'm wrong). With WvTnef there'd be support for directly handling
Outlook's native calendar/contacts/whatever objects.

Anyway, I just thought I'd mention it since it seemed relevant.

Have fun,

Peter Colijn