gerv's facebook thunderbird dreams, moving off of [Bug 408370] STEEL 0.1

[Andrew Sutherland]

(In reply to comment #40)
> (In reply to comment #38)
> > Ben, modifying message bodies is made basically impossible by the
IMAP case.
> > (We would need to completely add a new message that is the modified
copy, then
> > delete the original, as I understand it.) Also, I would call that
a major
> > hack.
>
> Isn't this exactly what we do for deleting attachments? :-)
>
> In this case though, it's not necessary for the updates to be
persisted to the
> IMAP data store. We just need them in the UI (and, thereby, acted upon by
> things like the Reply command). Is it possible to patch the in-memory
data? Or
> is the data object too closely tied to the IMAP copy? (Waves hands)
>
> Gerv

The "right" answer to this question is basically gloda and enhancing the
message reader. Or just a completely differing UI ignoring the message
reader.

The problem is that the message reader gets a surprising amount of its
data from the libmime streaming of the message. The only way to fix
that is to mutate the underlying message, but that is like traveling
back in time to make it so the guy who bumped into you and made you drop
your favorite coffee mug is never born. Yes, it solves the problem, but
inevitably the world you return to is ruled by dinosaurs.

Andrew

[Ben Lerner]

Ok, so from your response I gather that the dependency in the message
reader on libmime is too tight to be replaced by an enhanced gloda (at
least not yet). Caveat lector: I am not fluent with TB code, so the
below may be wildly off base...

I tried manually tracing through the code (on mxr) to figure out what's
happening as a message gets displayed, and found

http://mxr.mozilla.org/comm-central/source/mail/base/content/msgHdrViewOverlay.js#368

...which is the listener for MIME header-parsing events. And huzzah, it
has hooks for onStartHeaders, onEndHeaders, and processHeaders -- that
last one looks like exactly the place we want, in that we can tweak the
in-memory data (which is the currentHeaderData object). But it looks
like this hook isn't fully available to extensions. Instead, "other
components may listen to on start header & end header notifications",
and not individual headers, and moreover the end-header notifications
get delivered *after* the message has already been displayed
(specifically ShowMessageHeaderPane and UpdateMessageHeaders have
already been called).

So...could the ordering in onEndHeaders be reversed, to allow extensions
to access and maybe modify the currentHeaderData object? That would be
sufficient to enable Gerv's suggestion and other related ideas. Or is
there some subtle invariant that would break if that were permitted?

~ben

[Andrew Sutherland]

On 04/22/2009 05:21 PM, Ben Lerner wrote:
> Ok, so from your response I gather that the dependency in the message
> reader on libmime is too tight to be replaced by an enhanced gloda (at

I just meant that changing libmime or the input to libmime was overkill.
Changing things in the message reader, as you propose, is a much
happier way to go about it from my perspective.

> So...could the ordering in onEndHeaders be reversed, to allow extensions
> to access and maybe modify the currentHeaderData object? That would be
> sufficient to enable Gerv's suggestion and other related ideas. Or is
> there some subtle invariant that would break if that were permitted?

Dan Mosedale has been interacting with the message reader code the most
as of late, so he is probably most qualified to speak on it...

Although invariant is probably way too strong a word for it, I think a
reasonable approach might be to introduce an additional call prior to
onEndHeaders with the semantics you suggest.

Ideally, the message reader would have explicit extension points that
are 'supported' in that they aren't likely to break, are intended to let
multiple extensions play well together, and that we will try not to
break. I don't think the message reader is there right now, and I fear
it won't get there before TB3.0... as such, it seems reasonable to add
such a method for your use case, as long as everyone understands it's a
stop-gap measure (that will probably live a long and full life.)

Andrew

[Dan Mosedale]

On 4/22/09 5:57 PM, Andrew Sutherland wrote:
>
> Ideally, the message reader would have explicit extension points that
> are 'supported' in that they aren't likely to break, are intended to let
> multiple extensions play well together, and that we will try not to
> break. I don't think the message reader is there right now, and I fear
> it won't get there before TB3.0... as such, it seems reasonable to add
> such a method for your use case, as long as everyone understands it's a
> stop-gap measure (that will probably live a long and full life.)

This sounds like a wise-strategy to me. Ben, can you file a bug on that
in Bugzilla and CC dm...@mozilla.org on it? Bonus points for attaching
a patch. :-)

Dan