<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Dear tb-planning,<br>
<br>
Thanks to everyone for the nice answers and the followups to my
previous email. I'm glad I was able to start some discussion, and I'm
even happier to see that there are plans for an overhaul of the
internal APIs. Of the many things you mentioned, many of them will
simplify my life and I'm currently dreaming at night of removing big
chunks of ugly code from my extension :-) (especially the iframe
auto-resize code which is quite... head-banging).<br>
<br>
Before addressing Andrew's specific remarks below, I'd like to evoke
other points while I'm at it.<br>
<br>
1) We used to see really amazing extensions like this one:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.visophyte.org/blog/2009/04/01/thunderbird-gloda-exptoolbar-protovis-paninaro-oh-oh-oh/">http://www.visophyte.org/blog/2009/04/01/thunderbird-gloda-exptoolbar-protovis-paninaro-oh-oh-oh/</a><br>
<br>
It doesn't seem to be updated. Are there any plans to move this forward
/ maintain it? There are some other possibilities (see
<a class="moz-txt-link-freetext" href="http://flowingdata.com/2008/03/19/21-ways-to-visualize-and-explore-your-email-inbox/">http://flowingdata.com/2008/03/19/21-ways-to-visualize-and-explore-your-email-inbox/</a>
for instance) and I'm sure many people would be excited to see such
visualizations as "recommended" addons on AMO. Of course, once the APIs
are improved and manipulating messages is as easy as toggling a
<div> with jQuery, it will be even easier to build such things.
But what's the general stance on this?<br>
<br>
2) I stumbled upon bug 456814 a.k.a. "msgreadertracker", including
Bryan's amazing designs <a class="moz-txt-link-freetext" href="http://clarkbw.net/designs/msg-reader/">http://clarkbw.net/designs/msg-reader/</a> . What's
the current plan regarding this? Actually, visualizing attached images
inline as Bryan suggests in the mockups was one of the many things I
had in mind. Is this hard to do? Does this depend on offering better
APIs and better access to message parts?<br>
<br>
3) Now moving on to Andrew's comments :).<br>
<br>
On 03/19/2010 03:29 AM, Andrew Sutherland wrote:
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
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>
</blockquote>
This is indeed very appealing. I don't have much time right now, but I
can imagine submitting some patches to implement marking a message as
read, or similar things. Would this be a useful effort or do you plan
on tackling this in the near future? I'm asking because the bug is a
bit old already, but if there is a hope of landing such patches
quickly, I think it might be worth the effort for me.<br>
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite"> <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>
</blockquote>
That's one of the major pains involved with Gloda, and that accouts for
90% of the bug reports I receive concerning my extension. I'd be glad
to hear when it's fixed! Is there any specific bug involved?<br>
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite"> <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 moz-do-not-send="true" 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>
</blockquote>
I CC'd myself, and this is definitely what I envisioned. As I said, I'd
be glad to contribute to that bug rather than baking my own
quick-hacked .jsm that really isn't useful to anyone.<br>
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite"> <br>
<br>
<blockquote cite="mid:4BA14CBD.1090801@gmail.com" type="cite">① I
needed to display messages using the regular display code. (...)<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>
</blockquote>
I'm going to post some directions on MDC because I think that really
was missing.<br>
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite"> <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>
</blockquote>
Sure. But at least providing wrappers to display a message simply will
already be a big step forward. Of course we're depending on bug 80713
here... is there any possible way to lure roc into fixing this ? ;-)<br>
<br>
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite">
<blockquote cite="mid:4BA14CBD.1090801@gmail.com" type="cite"> 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. </blockquote>
How do I "tell" Gloda that all the headers are in the same thread? I'm
just calling getMessageCollectionForHeaders with all the selected
messages from the dbView. Is that what you meant?<br>
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite">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>
</blockquote>
I guess I was not aware that msgQueries has a .conversation property. I
know that GlodaMessages have... anyway, I'll try to re-think that, and
I know for sure how to do it properly. Once again, the issue is that
all I have as a reference is<br>
<br>
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en/Thunderbird/Gloda_examples">https://developer.mozilla.org/en/Thunderbird/Gloda_examples</a><br>
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en/Thunderbird/Creating_a_Gloda_message_query">https://developer.mozilla.org/en/Thunderbird/Creating_a_Gloda_message_query</a><br>
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite"> <br>
For the author of a message, you should be pulling it off the "from"
attribute on a fully indexed gloda message representation.<br>
</blockquote>
I was thinking this because of:<br>
<br>
<a class="moz-txt-link-freetext" href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#311">http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#311</a><br>
<br>
<pre lang="en"><a class="l d2" name="307"
href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#307">307</a> <span
class="v">let </span>[<a class="d"
href="http://mxr.mozilla.org/comm-central/ident?i=text">text</a>, <a
class="d" href="http://mxr.mozilla.org/comm-central/ident?i=meta">meta</a>] = <a
class="d"
href="http://mxr.mozilla.org/comm-central/ident?i=mimeMsgToContentSnippetAndMeta">mimeMsgToContentSnippetAndMeta</a>(<a
class="d" href="http://mxr.mozilla.org/comm-central/ident?i=aMimeMsg">aMimeMsg</a>,
<a class="l d2" name="308"
href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#308">308</a> <a
class="d" href="http://mxr.mozilla.org/comm-central/ident?i=aMsgHdr">aMsgHdr</a>.<a
class="d" href="http://mxr.mozilla.org/comm-central/ident?i=folder">folder</a>,
<a class="l d2" name="309"
href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#309">309</a> <a
class="d"
href="http://mxr.mozilla.org/comm-central/ident?i=SNIPPET_LENGTH">SNIPPET_LENGTH</a>);
<a class="l d2" name="310"
href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#310">310</a> <a
class="d"
href="http://mxr.mozilla.org/comm-central/ident?i=snippetNode">snippetNode</a>.<a
class="d"
href="http://mxr.mozilla.org/comm-central/ident?i=textContent">textContent</a> = <a
class="d" href="http://mxr.mozilla.org/comm-central/ident?i=text">text</a>;
<a class="l d2" name="311"
href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#311">311</a> <span
class="v">if </span>(<a class="d"
href="http://mxr.mozilla.org/comm-central/ident?i=meta">meta</a>.<a
class="d" href="http://mxr.mozilla.org/comm-central/ident?i=author">author</a>)
<a class="l d2" name="312"
href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#312">312</a> <a
class="d" href="http://mxr.mozilla.org/comm-central/ident?i=authorNode">authorNode</a>.<a
class="d"
href="http://mxr.mozilla.org/comm-central/ident?i=textContent">textContent</a> = <a
class="d" href="http://mxr.mozilla.org/comm-central/ident?i=meta">meta</a>.<a
class="d" href="http://mxr.mozilla.org/comm-central/ident?i=author">author</a>;
</pre>
<br>
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite"> <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>
</blockquote>
Sure :).<br>
<blockquote cite="mid:4BA2E183.5020601@asutherland.org" type="cite"> <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 moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://developer.mozilla.org/en/DOM/element.classList">https://developer.mozilla.org/en/DOM/element.classList</a><br>
</blockquote>
Wonderful, I wasn't aware of that as well :(. I guess I didn't read the
release notes closely enough.<br>
<br>
jonathan<br>
</body>
</html>