On Wed, 2005-04-06 at 16:27 +0800, Not Zed wrote: <snip> > Right. Well, I think, considering that this code already changes > camel-gpg-context, and that is probably the easiest/cleanest way to do > this, I don't see a problem in actually implementing this more in the > core code than just doing it as a plugin; aside from demonstrating it > could be done in a plugin. > > Since: > - the additions to em-inline-filter should be small. > - the changes to camel-gpg-context are small. > - the only other thing needed is a application/x-inline-pgp 'handler', > which should be really quite small (maybe it will need to distinguish > between signed/encrypted somehow, but header parameters or a separate > type could do that).
I agree with everything previous. However, I think we only need to use an application/x-inline-pgp type for inline signed messages. For encrypted messages it is easy to build a multipart/encrypted and pass that to the decrypt function. If you want to use application/x-inline-pgp for encrypted messages as well, there will need to be more modifications to camel-gpg-filter along the lines of those I've already made for signed messages. > The benefits are: > - the inline filter already exists and already handles streaming and > various other bits and pieces > - less data copying/processing on every message view, when the plugin > is enabled > - it should be less code ACK :) Thanks to you and Jeff for your helpful comments. -- Matt Brown [EMAIL PROTECTED] Mob +64 275 611 544 www.mattb.net.nz _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
