New Account Types directions - should SkinkGlue be core?

David Bienvenu dbienvenu at
Fri Jun 3 17:18:28 UTC 2011

On 6/2/2011 11:29 PM, Kent James wrote:
> On 6/2/2011 10:40 AM, David Bienvenu wrote:
>> 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.
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.
> 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 in a tab, and call that "Twitter support" - but that is not really what we are talking about here.
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.
> 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).
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...
> 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.
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.
>> 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?
yes, that's highly desirable.
> 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.
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.

- David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list