On Wed, 2005-04-06 at 16:27 +0800, Not Zed wrote: > > > > As for the processor code - it isn't particularly elegant, relies on > > > brute-force and bulky handling, etc. As much code as possible is > > > implemented using stream processes. These are harder to write but are > > > more efficient. > > > > Fair comment, I have struggled a bit understanding exactly how some of > > the internals of Evolution work as I've been writing this, so it's not > > surprising it shows in the patch! > > > > I have the plugin mostly implemented using CamelMimeFilter as well, but > > it was plagued with lots of bugs that I could not track down, so I > > abandoned it and rewrote the current plugin in an hour or two. > > > > Given your comments it sounds like I should go back to my original > > architecture and try and discover where the bugs are! > > Well, i guess if it is going to be impossible ... maybe we need to > rethink some of the ideas here, too. > > > > > a scanner which looks for the armoured parts. > > > a formatter which handles that type of part. > > > do more streaming. > > > > OK, I'll keep that it mind. > > > > > Also, since you do have control over all of it, you could perhaps do > > > the camel stuff too from the plugin itself, but i guess there is a lot > > > of extra work in doing that if you can't re-use the gpg-context as is. > > > Its just that if you're going to have to make code changes to core > > > camel outside of the plugin, there might not be much point in doing it > > > as a plugin, since the inline scanner already available could be > > > modified only slightly to do most of the work required, and just add a > > > new x-inline-pgp handler for the other glue (similar to the > > > multipart/signed handler, etc). > > > > I had wondered this myself, I guess the only reason I implemented it as > > a plugin is that it was suggested it would be more likely to be accepted > > I think Jeff may disagree with me here, but there are some hooks > around already for detecting structured content in plain-text parts, > and I think it makes sense to keep that together as much as possible > to avoid excessive over-processing. no, it's fine. whatever's cleanest -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. fejj ximian com - www.novell.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature