Re: [Evolution-hackers] Bug #232

Well, it's doesn't handle *all* MAPI properties, but it does support for external programs to read them and do with them as they wish, using the same GUID+id syntax you mentioned.

ytnef is mostly designed to take a tnef stream (winmail.dat), and strip out allthe attachments.  This includes all calendar entries, contact cards, and tasks, which are saved as vCal/vCard entries (plaintext).  But using the library, you can save these entries as anything you want, it's just a long list of queries for certain ID's.  The 2 main things that it does not support right now is Compressed RTF and Recurring calendar entries.  But I use it for all my tnef streams (procmail script to automatically process email) and haven't found a stream that broke it yet :)

On Tue, 2003-11-18 at 15:14, Peter Colijn wrote:
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

evolution-hackers maillist  -  evolution-hackers lists ximian com
Randall E. Hand
Senior Software Engineer
Z-KAT, Inc.
2901 Simms Street
Hollywood, FL 33020
Office 954.927.2044 x125
fax 954.927.0446
"the digital surgery companytm"

Digital signature stored at
ID: 0xDD4B4C4A
Fingerprint: F0A7 3E89 BD49 FDEB CCE4  2FB1 DC9D 83E1 DD4B 4C4A

Attention: The information contained in this e-mail message is privileged and confidential information intended only for the use of the individual(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copy of this communication is strictly prohibited. If you have received this communication in error, please contact the sender by reply E-mail and destroy all copies of the original message.

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]