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 http://lists.ximian.com/mailman/listinfo/evolution-hackers
Digital signature stored at www.keyserver.net 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