<!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>