<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
First, thank you very much for composing this message; this is
exactly what I was hoping for! I'm going to mainly try and reply in
terms of what the plans are from my perspective to address these
problems. These are going to tend to be gloda-centric plans that
assume that you are generally starting from a gloda message
abstraction in the first place. Direct interaction with nsIMsgDBHdr
instances is not something I am trying to facilitate. This is
unfortunately at odds with most current realities but is a
cost/benefit necessity to ever escape the current realities.<br>
<br>
The good news is that there are ways to go from nsIMsgDBHdr
instances to gloda instances, as you are aware. The bad news is
that there is currently no guarantee that there will be a gloda
message for the message you want and the indexer does nothing to
help you out. The good news is that we're very close to being able
to resolve that.<br>
<br>
<br>
On 03/17/2010 02:42 PM, Jonathan Protzenko wrote:
<blockquote cite="mid:4BA14CBD.1090801@gmail.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
One big disappointment to me was the fact that STEEL (and, by the
way,
FUEL) seems to be completely abandoned. I was hoping for a real
"standard library" for Thunderbird extensions, providing wrappers
for
extremely common actions such as getting the contents of a mail,
marking a message as read... However, no such thing exists. The
only
useful resource is MDC [3] which is extremely sparse.<br>
</blockquote>
<br>
The going forward plan has been to fuse the STEEL message
manipulation goals into the gloda representations. This has been
somewhat complicated by need to decouple the action mechanism enough
that it can be used on messages that are not backed by nsIMsgDBHdr
instances.<br>
<br>
The gloda bug for that is here:<br>
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=468283">https://bugzilla.mozilla.org/show_bug.cgi?id=468283</a><br>
<br>
The STEEL bug which has some discussion on strategy but is not
required reading is here:<br>
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=408370">https://bugzilla.mozilla.org/show_bug.cgi?id=408370</a><br>
<br>
There are some test-only helpers that might provide some insight on
how to perform various manipulations, but being test-only they may
not generate the proper event cascades required in reality:<br>
<a class="moz-txt-link-freetext" href="http://mxr.mozilla.org/comm-central/source/mailnews/test/resources/messageModifier.js">http://mxr.mozilla.org/comm-central/source/mailnews/test/resources/messageModifier.js</a><br>
<br>
<br>
<blockquote cite="mid:4BA14CBD.1090801@gmail.com" type="cite">①
I needed to display messages using the regular display code. That
is,
using the HTML if the message has HTML, but stripped of all JS,
with
images blocked according to the global security policy. I first
thought
that Gloda would offer a wrapper for that. But all I could find
was
GlodaMessage::coerceBodyToPlaintext. That was pretty useful, but I
found it odd that, given that all the MIME structure was built, no
such
equivalent was available for the HTML contents. I wrote a custom
function that recursively walks down the
GlodaMessage's .parts and returns whatever has contentType
"text/html"
and
looks like a "message body". However, JS is not stripped, images
are
not blocked... I finally resorted to copying nsMessenger.cpp's
behavior
using loadURI, nsIMarkupDocumentViewer and nice gory details such
as
hintCharacterSetSource on the contentViewer.<br>
</blockquote>
<br>
This is going to be a big area for future work. You are doing the
right thing by using the existing code path when involving HTML
messages (as HTML) and probably all other extension authors should
follow your lead here.<br>
<br>
Our dream is to be able to display messages with extensions being
able to contribute annotations and additional mark-up in an easy
fashion. Because there are so many security concerns and potential
interaction problems between multiple extensions trying to do the
same thing, I think it's going to take a very concerted effort to
improve this.<br>
<br>
<br>
<blockquote cite="mid:4BA14CBD.1090801@gmail.com" type="cite">
To be even more specific, Gloda conversations respect "strict
threading". This means that when my extension is used in
conjunction
with mail.strict_threading set to false, I need to repeat the
two-part
process for each message in the "false thread" because Gloda won't
relate these messages together in a GlodaConversation. The Gloda
logic
is perfectly fine, it's nice to have strong semantics, but once
again
I'd need a getConversation*s*ForHeader*s*.<br>
</blockquote>
<br>
This use-case is pretty atypical. But you could save yourself a lot
of work by just using getMessageCollectionForHeaders telling it all
the headers that the db view is telling you are in the same thread
at once. Then do a single pass to figure out all the distinct
conversations involved and ask those conversations for their
messages in a single query (ex:
msgQuery.conversation.apply(msgQuery,
listOfDistinctConversationIdsICalculated);)<br>
<br>
Patches / extensions to change gloda's conversation logic to be more
clever are obviously also possibilities, although likely to be more
of an undertaking.<br>
<br>
<blockquote cite="mid:4BA14CBD.1090801@gmail.com" type="cite">
<span id="summary_alias_container"><span
id="short_desc_nonedit_display"></span></span>-
mimeMsgToContentSnippetAndMeta's meta part never seems to return
the
author properly. Ideally, that would be a GlodaIdentity that
corresponds to the name stored in the Address Book.<br>
</blockquote>
<br>
This isn't really intended to provide any information about the
author. Because the content whittlers are also used as part of the
message indexing process, there may be some ad hoc communication
from contentWhittle intended for consumption by their owning
indexer, but that's it. For example, the bugzilla content whittler
does this because not all of the information about the initiator of
a bugzilla action is available from the headers but instead has to
be parsed out.<br>
<br>
For the author of a message, you should be pulling it off the "from"
attribute on a fully indexed gloda message representation.<br>
<br>
<blockquote cite="mid:4BA14CBD.1090801@gmail.com" type="cite">- the
ability to make a difference between a forwarded message and a
"real" attachment (currently, both have .isRealAttachment set to
true).<br>
</blockquote>
<br>
I would categorize this as a bug; I doubt there's any case where we
would want to categorize it as such. Please feel free to log a bug.<br>
<br>
<br>
<blockquote cite="mid:4BA14CBD.1090801@gmail.com" type="cite">
There are definitely more and more parts of the UI that use HTML
(search results, thread summaries). What a shame that functions
such as
_mm_addClass, _mm_removeClass are defined locally and not made
available in a .jsm somewhere for extension developers! I partly
used
jQuery at the beginning, but as I really was not satisfied (slows
things down, does not always play nice with XUL, spits tons of
errors),
I resorted to more old-style DOM code. I'm unsure as to what is
the
best solution here.<br>
</blockquote>
<br>
Thunderbird 3.1 supports the new element.classList magic and the
ship has sailed on Thunderbird 3.0 for adding that so that
extensions can always assume it is present, so classList is the way
to go:<br>
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en/DOM/element.classList">https://developer.mozilla.org/en/DOM/element.classList</a><br>
<br>
<br>
Andrew<br>
</body>
</html>