New Account Types directions - should SkinkGlue be core?

Kent James kent at
Tue Apr 26 20:16:11 UTC 2011

This post is requesting that the Thunderbird developer community give 
feedback on the SkinkGlue approach to new account types in Thunderbird.

In dmose's existing Thunderbird product direction 
<>, one of seven 
product priorities is:

''Thunderbird will focus on conversations that occur over mainstream and 
emerging communication channels. These include email, web forums, social 
networks, and microblogging services."

I interpret that as a priority that Thunderbird should be able to 
integrate new account types beyond RSS, IMAP, and POP3 using extensions.

Although jcranmer did a series of blog postings 
<> on trying to add some new 
communication channels to Thunderbird using javascript, so far this has 
not resulted in a workable approach. In December of 2010 I investigated 
an alternative approach <> that 
created a JavaScript-overridable version of key mailnews objects, which 
I call SkinkGlue <>. (For the 
AMO entry for SkinkGlue 
I call it by the friendlier but boring name of "New Account Types"). I 
also created a demonstration extension that uses SkinkGlue called 
TweeQuilla <>, showing what 
it takes to implement Twitter into Thunderbird using JavaScript plus 
SkinkGlue. Source code for SkinkGlue 
<> and TweeQuilla 
<> are available 
publicly, and released with a standard Mozilla tri-license. 
(Unfortunately the AMO versions of these got caught in AMO review queues 
and issues. I need to do a new blog posting with self-hosted versions of 
these for testing.)

 From my perspective, the developer reception to the SkinkGlue-based 
approach has been lukewarm. I've heard complaints that it is based on 
the mork nsIMsgDatabase implementations rather than gloda, and that the 
overridable API that is key to its working seems like a kludge. I 
haven't really heard any encouraging statements.

After having used the SkinkGlue API to develop a couple of new account 
types now (Twitter and Exchange Web Services), my experience is that 
overriding the base C++ mailnews objects with JavaScript components is 
not any more difficult than the equivalent overriding in a C++ XPCOM 
object. As far as I can tell, the approach works just fine. The approach 
of using a base C++ object that take responsibility for calling any 
JavaScript overrides also avoids subtle issues like bug 606465 
<> which occur in 
email classes as well.

It will be difficult for SkinkGlue to be effective for anyone other than 
myself as long as it remains a binary addon, which are discouraged in 
AMO and difficult to maintain. If this is the near-term approach that 
Thunderbird plans to take to new account types, it really should be 
shipped with the core product so that extensions do not need to deal 
with a separate binary extension. The Windows version is a 201KB dll 
file (if incorporated into libxul it would probably be smaller).

So I am asking the question, is there any interest in make SkinkGlue 
part of the core Thunderbird distribution?

I'm looking for more here than the usual "If you put a lot of work into 
making this viable, then we might consider adding it to core".  If new 
account types are a strategic priority, and SkinkGlue is an important 
supported approach to that, then I would expect to see other people who 
are willing to try using it to add a simple new account type. (It would 
also be great for someone with Mac experience to review the C++ code to 
see what it takes to be compilable there). I'd also like to see some 
sort of higher level decision, more than just an r+ on a bug, that shows 
some commitments to this direction. Without that, I will probably just 
to keep this in my own little private MesQuilla <> 

So what is the interest in this?


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

More information about the tb-planning mailing list