New Account Types directions - should SkinkGlue be core?

Kent James kent at
Fri Jun 3 06:29:50 UTC 2011

On 6/2/2011 10:40 AM, David Bienvenu wrote:
> I much prefer fixing the underlying issues Skink has to work around to 
> putting the work-arounds in Skink. If we were to take Skink into the 
> core code, I would want it to be as simple as possible to cut down on 
> maintenance costs. Re the [noscript] methods, there are about 12 in 
> the core base and db classes, and half of them have to do with 
> collation keys. I think those could be made scriptable by changing the 
> idl to specify an out array of octets.  The db methods that use 
> nsTArray could be changed as well.
(Just to be clear, in my terminology "Skink" is the ugly set of 
interfaces that I have to deal with in the core code. I'll rename those 
to "Swan" when and if they become pretty ;) )

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.
> The pluggable store work deals with some of the same issues that Skink 
> has to (e.g., folder discovery, db handling, etc).  So, as Andrew 
> suggested, the pluggable store stuff would need to land first, but 
> beyond that, I'd like to make it so Skink doesn't have to deal with 
> workarounds. The pluggable store work is an opportunity to clean it 
> up, since it already has to change that code.
Looking forward to seeing that land.
> I'd still really like to have a mechanism for adding content to 
> Thunderbird that wasn't so closely tied to the existing heavyweight 
> folder+server+url classes. That mechanism could simply provide simple 
> hooks for getting the content into a pluggable store that looks like a 
> local mailbox to Thunderbird and the pluggable store could deal with 
> getting the content.
> The more you want that to look like our existing data sources 
> (IMAP/Local/NNTP messages), the more you want to re-use the existing 
> infrastructure. So Skink makes more sense for things like Exchange 
> support. For something like twitter feeds, clicking on a twitter 
> folder pane item could display something like a snowl-type stream and 
> not play at all the existing infrastructure. The js folder pane allows 
> you to have non-nsIMsgFolder items, and you can make selecting the 
> item do whatever you want.
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.

Something that I use with TweeQuilla for example is "Starring" tweets, 
and then displaying them along with mailnews items in a single Starred 
virtual folder that represent items that I need to followup.

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).

These are really important questions that I think we should be 
discussing here rather than what seems to get lots of interest. We 
suffer from the "color of the bike shed" problem sometimes.

> I really like the fact that Skinkglue allows you to write js account 
> types relatively easily. The code is fairly clean considering the 
> difficult problem it's solving. The main drawback is that it has to 
> deal with all the core mailnews interfaces. I don't see those going 
> away anytime soon. Skinkglue might lessen the pressure for those to go 
> away, which is not good, but it also allows more stuff to be done in 
> js, which is a win.
I would say actually that another "main drawback" is the need to use a 
C++ - based implementation as prototypes for js objects.

So really SkinkGlue does these four things:

1) provides workarounds and interface implementations for non-scriptable 
2) implements common functions such as folder discovery and database 
3) solves certain issues that are not handled properly in xpconnect 
(like the issue of returning null pointers as out items)
4) provides a mechanism to use and selectively override the existing 
standard object implementions of things like nsMsgDBFolder and 

1) and 3) are solvable through code cleanup.

You say that 2) is at least partly handled by the pluggable store code.

4) though is still an important issue.

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.

> The path for Skinkglue getting into core would look something like this:
>     * Fix the core interfaces wherever practical to be scriptable so
>       that Skinkglue an be simplified.
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 
>     * Adapt Skinkglue to deal with pluggable stores and try to make
>       the pluggable store code lessen the need for workarounds in
>       Skinkglue
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.
>     * Some sort of unit tests (e.g., tweequilla)
Just as nsMsgDBFolder does not really have unit tests, SkinkGlue's tests 
ideally would be an implementation of a particular data type that has 
its own tests. My Exchange Server extension has some basic unit tests in 
it for example that exercises SKinkGlue (though by no means exhaustively).

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

More information about the tb-planning mailing list