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




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

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. 

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).

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

If it turns out to be more difficult than all that, then perhaps a fallback to this plugin approach will do - with some very minor changes most of the real code inefficiencies can be cleaned up.  At the end of the day having something that works inefficiently is better than something that doesn't work at all.

Thanks,
Michael



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