New Account Types directions - should SkinkGlue be core?

Andrew Sutherland asutherland at
Fri Apr 29 17:10:26 UTC 2011

On 04/26/2011 01:16 PM, Kent James wrote:
> So I am asking the question, is there any interest in make SkinkGlue 
> part of the core Thunderbird distribution?

I would propose we do the following:

1) Review and land the skink glue stuff (possibly after bienvenu lands 
pluggable storage?), BUT:
2) Make its building conditional on a --enable-skink-glue or equivalent 
magic AND
3) Only --enable-skink-glue on the "Thunderbird Experimental" stream 
builders (and for developers, somehow).  Not beta, not release.
4) Gate its enabling on beta (and eventually stable) on there being a 
JS-based account type that we want to broadly distribute either as part 
of the product or as an endorsed extension.

The rationale is this:

a) You are right, everyone hates binary add-ons and in the new train 
model what was previously a highly unpleasant experience for binary 
add-ons is now a nightmare.  Accordingly, it would be a catch-22 for 
SkinkGlue to prove its worth given that it would be hard for people to 
use it at all.

b) SkinkGlue is currently the only viable JS-based new account model and 
this is a nice thing for people to be able to experiment with, but it 
needs more testing with crash-stats feedback before wide-scale 
distribution.  The other alternatives for new account types do not 
appear likely to be competitive anytime soon.  Joshua's solution is 
technically interesting but also terrifying, and the gloda solution 
(which would also require UI layer work) is not currently being worked.

c) TweeQuilla is an excellent open-source example use-case.  Kudos!

d) As a long-term active contributor to Thunderbird it seems unlikely 
you'd land it and disappear leaving us without anyone willing to hack on 
it.  Given that SkinkGlue does not seem particularly technically risky, 
just more of a maintenance thing, as long as you are willing to be 
module owner and keep it up-to-date in the form of collaborating on 
patches with any changes being made to the C++ back-end, it should not 
significantly increase code burden for the tree.

The important caveat is that this is not my call, especially as I would 
not be dealing with any of the additional code complexity, etc.


More information about the tb-planning mailing list