<!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 bgcolor="#ffffff" text="#000000">
    On 6/2/2011 11:29 PM, Kent James wrote:
    <blockquote cite="mid:4DE87F5E.3040608@caspia.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <title></title>
      On 6/2/2011 10:40 AM, David Bienvenu wrote:
      <blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=ISO-8859-1">
        I am encouraged to see a pretty clear commitment from you that
        cleaning up these interfaces to better support js is valuable.
        You've probably thought that for awhile, but occasional comments
        from you (like a recent hesitation to remove the TArray db
        methods) left me in doubt. It's much harder for me to get
        motivated to work on things that I think will be only accepted
        reluctantly, than things that are really wanted.<br>
      </blockquote>
    </blockquote>
    I don't remember that discussion, to be honest. I don't want to
    remove those methods, but I'd be happy to replace them with
    nsIMutableArrays or the like.  I do remember not wanting to remove
    nsIURI return values for some methods but that was an discussion
    about how to make the methods compatible with Skinkglue, not whether
    to.<br>
    <blockquote cite="mid:4DE87F5E.3040608@caspia.com" type="cite">
      <blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite"> </blockquote>
      It's a really important issue, whether or not new data sources
      appear enough like the older sources so that all of the standard
      UI bells and whistles can work with them. I'm thinking of things
      like tagging, marking as read, combining into virtual folders with
      mail items, filtering, threading, grouped headers, etc. You could
      always just include <a moz-do-not-send="true"
        class="moz-txt-link-freetext" href="http://twitter.com">http://twitter.com</a>
      in a tab, and call that "Twitter support" - but that is not really
      what we are talking about here.<br>
    </blockquote>
    It depends on the user and the data source. I'd be happy with a UI
    that lets me easily save an individual tweet into a folder but lets
    me read them in batches as a stream and doesn't require me to mark
    them read or god forbid, read them one at a time. Tweets are by
    default ephemeral, which is different (usually) from my e-mail.<br>
    <blockquote cite="mid:4DE87F5E.3040608@caspia.com" type="cite"> <br>
      My own vision is that a messaging client needs to be able to
      include as much as possible a set of standard features that are
      supported across a wide variety of data sources - and yet there
      still needs to be unique differences for each. So I think that the
      main point would be lost if new data items could not easily play
      with the existing infrastructure (and by that I mean user-facing
      issues like tagging, not nsIMsgDBHdr).<br>
    </blockquote>
    I'm not disagreeing - I'm saying there are some data sources where
    it's much less important. That's not the same as saying there aren't
    data sources where it is important. Obviously there are...<br>
    <blockquote cite="mid:4DE87F5E.3040608@caspia.com" type="cite"> <br>
      To have any hope of new data items reliably supporting an existing
      robust infrastructure, then the data items need to be able to
      inherit from an existing implementation of things like servers,
      folders and items. A key question is whether in the foreseeable
      future Thunderbird will provide js language versions of those
      things (like Calendar's ProviderBase for example). If not, does
      each new data source implement their own, or will something like
      the msqIOverridable interface be provided to allow using the
      existing C++ prototypes? This issue you have not really addressed.<br>
    </blockquote>
    Providing js versions of those objects is definitely something we'd
    like to do. But it would involve a complete redesign of the
    interfaces; they're extremely unwieldy. There's an obvious tension
    between a desire to throw away the current interfaces and start
    over, or to make it possible to implement the current interfaces in
    js soon. <br>
    <blockquote cite="mid:4DE87F5E.3040608@caspia.com" type="cite"><br>
      <blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite">
        Is it fair to say that there is a general commitment to the idea
        of solving the issues that SkinkGlue has identified in the core
        code, to move closer to allowing creating of new data items with
        javascript implementations?<br>
      </blockquote>
    </blockquote>
    yes, that's highly desirable.<br>
    <blockquote cite="mid:4DE87F5E.3040608@caspia.com" type="cite"> My
      existing Exchange data types derive from the C++ SkinkGlue
      objects, so I will be continuing to adapt it to changes in the
      core code. Suggestions would be more than welcome here.<br>
    </blockquote>
    Pluggable stores in the context of remote servers like IMAP or
    Exchange really just affects offline storage and offline folder
    discovery. I'm guessing that you don't need to do much to adapt to
    pluggable stores, if you're using the base classes (e.g.,
    nsMsgDBFolder::GetOfflineStoreInput/OutputStream) and pattern your
    code somewhat after the IMAP code. But I'm happy answer any
    questions you have about it.<br>
    <br>
    - David<br>
    <br>
  </body>
</html>