Re: [Evolution-hackers] Preliminary patches to add inline PGP support



On Wed, 2005-04-06 at 10:46 +0800, Not Zed wrote:

> I'm totally not a fan of having one function called in one place at
> the end of another function which is only called in one place, either.
> 
> i.e. adding a new subroutine is redundant in this case, i'd just put
> all the code in gpg_verify, all it is is a slight re-order of the
> existing code anyway.

OK. I've got no problems moving this into a single function. 

> 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!

> 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
as a plugin. Unfortunately I don't think it's possible to fake a
multipart/signed message from a message with an inline signature so
modifications to camel-gpg-context will be needed. 

It's worth noting that my original implementation (ie. the one using
CamelMimeFilter) is pretty much identical to the existing inline scanner
and would be able to added to it (rather than being a module) very very
easily. 

-- 
Matt Brown
matt mattb net nz
Mob +64 275 611 544 www.mattb.net.nz






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