<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 03/22/2010 02:40 PM, Jonathan Protzenko wrote:
    <blockquote cite="mid:4BA7E3C8.8010205@gmail.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <title></title>
      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>
    <br>
    This would be very useful.  As long as you don't mind writing unit
    tests at the same time, there is hope of landing such patches
    quickly.<br>
    <br>
    I should probably be explicit that I don't need to be the one to
    write any of this code, and I certainly don't want to stand in the
    way of improving things.  The eternal issue is one of limited
    resources and competing priorities.  The closer the dot product of
    the direction you are headed and the direction I am headed is closer
    to 1, the greater the time I am willing to spend reviewing things,
    etc.  The better the unit tests, the easier the review.<br>
    <br>
    I'm not sure if you were proposing writing a friendly nsIMsgDBHdr
    manipulation library independent of gloda or buying into the gloda
    vision whole hog.  While I'd be super psyched if you want a cauldron
    of gloda kool-aid since gloda would benefit from having
    working/tested nsIMsgDBHdr manipulation code in the tree, I'm also
    okay if you want to just start with a more pragmatic nsIMsgDBHdr
    helper library too.  (Not that I wouldn't write modular code with
    unit tests and such, I just would not be concerned about
    establishing a documented, stable extension-facing API independent
    of gloda that is nsIMsgDBHdr-centric.)<br>
    <br>
    <br>
    <blockquote cite="mid:4BA7E3C8.8010205@gmail.com" type="cite">
      <blockquote cite="mid:4BA2E183.5020601@asutherland.org"
        type="cite">
        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>
    <br>
    I have created the following bug to track this:<br>
    <a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=554190">https://bugzilla.mozilla.org/show_bug.cgi?id=554190</a><br>
    <br>
    I am not actively working it at this time; if you are interested in
    working on this bug or others, please feel free to drop a note on
    the bug and I'll be sure to avoid duplicating any work.  I'd also be
    very happy to provide suggestions or answer questions you might have
    about the code.  For example, one could easily start playing around
    with this bug by using GlodaIndexer.killActiveJob(),
    GlodaIndexer.purgeJobsUsingFilter(aFilterFunc), manipulation of the
    GlodaIndexer._indexQueue, and helper methods like
    GlodaMsgIndexer.indexFolder/GlodaMsgIndexer.indexMessages in order
    to get started with this.<br>
    <br>
    My immediate gloda enhancement focuses for 3.1 are on performing
    indexing and search performance which has more to do with
    inefficient queries and tokenizer limitations and much less to do
    with enhancements, so I doubt there would be much contention.<br>
    <br>
    <br>
    <blockquote cite="mid:4BA7E3C8.8010205@gmail.com" type="cite">
      <blockquote cite="mid:4BA2E183.5020601@asutherland.org"
        type="cite"> 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>
    <br>
    This would be fantastic!<br>
    <br>
    <blockquote cite="mid:4BA7E3C8.8010205@gmail.com" type="cite">
      <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>
    </blockquote>
    <br>
    Wrappers would also be fantastic!<br>
    <br>
    I think the core of the point I want to make is just that a lot of
    the code is a painful twisty maze of control flow and that it might
    not be an entirely bad call to just start from near-scratch rather
    than trying to work within the system.  Wrapping the current
    streaming process in a sane abstraction seems like an excellent
    effort.  Trying to do the blue sky dream I suggest above sounds more
    like a case to consider a near-scratch rewrite informed by the
    existing code.<br>
    <br>
    I'm not suggesting writing an HTML parser in JavaScript, though;
    more like leveraging more modern stuff from the mozilla platform
    that is at least somewhat supported.  For example, I think jcranmer
    was looking into exposing an HTML parsing engine to script which
    would be much better than trying to improve an existing C++ HTML
    parser-magicker, even if it is driven by the same HTML parser.<br>
    <br>
    <br>
    <blockquote cite="mid:4BA7E3C8.8010205@gmail.com" type="cite">
      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>
    <br>
    Yes.<br>
    <br>
    <blockquote cite="mid:4BA7E3C8.8010205@gmail.com" type="cite">
      <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 moz-do-not-send="true" 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 moz-do-not-send="true" 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>
    <br>
    While I'm not going to claim the existing gloda documentation is the
    be-all and end-all, the creating a gloda message query page does
    mention the conversation property.  In general, any attribute
    exposed on a gloda object should also able to be queried upon.<br>
    <br>
    The unit tests have some potentially useful examples for querying on
    messages:<br>
<a class="moz-txt-link-freetext" href="http://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/test/unit/base_query_messages.js">http://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/test/unit/base_query_messages.js</a><br>
    <br>
    Probably the best way for me to improve the documentation is for you
    to shoot me an e-mail or ping me on IRC with your question and I'll
    update the documentation in response.  Don't worry about
    investigating things before asking.<br>
    <br>
    <blockquote cite="mid:4BA7E3C8.8010205@gmail.com" type="cite">
      I was thinking this because of:<br>
      <br>
      <a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=text">text</a>, <a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=meta">meta</a>] = <a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=mimeMsgToContentSnippetAndMeta">mimeMsgToContentSnippetAndMeta</a>(<a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=aMimeMsg">aMimeMsg</a>,
<a moz-do-not-send="true" class="l d2" name="308" href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#308">308</a>                                                             <a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=aMsgHdr">aMsgHdr</a>.<a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=folder">folder</a>,
<a moz-do-not-send="true" class="l d2" name="309" href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#309">309</a>                                                             <a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=SNIPPET_LENGTH">SNIPPET_LENGTH</a>);
<a moz-do-not-send="true" class="l d2" name="310" href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#310">310</a>           <a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=snippetNode">snippetNode</a>.<a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=textContent">textContent</a> = <a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=text">text</a>;
<a moz-do-not-send="true" 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 moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=meta">meta</a>.<a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=author">author</a>)
<a moz-do-not-send="true" class="l d2" name="312" href="http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#312">312</a>             <a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=authorNode">authorNode</a>.<a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=textContent">textContent</a> = <a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=meta">meta</a>.<a moz-do-not-send="true" class="d" href="http://mxr.mozilla.org/comm-central/ident?i=author">author</a>;
</pre>
    </blockquote>
    <br>
    Ah.  Yeah, that's very misleading.  I think davida was coding
    explicitly against the bugzilla gloda plugin there.  <br>
    <br>
    <br>
    <blockquote cite="mid:4BA7E3C8.8010205@gmail.com" type="cite">
      <blockquote cite="mid:4BA2E183.5020601@asutherland.org"
        type="cite">
        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>
      <br>
      Wonderful, I wasn't aware of that as well :(. I guess I didn't
      read the
      release notes closely enough.<br>
    </blockquote>
    <br>
    I only knew about it because of a recent planet.mozilla.org blog
    post about Firefox 3.6's support of the feature :)<br>
    <br>
    Andrew<br>
  </body>
</html>