New Account Types directions - should SkinkGlue be core?

David Bienvenu dbienvenu at
Thu Jun 2 17:40:53 UTC 2011

Apologies for not commenting on this thread - during the MoMo Moco merger, mailman thought it would be funny to turn off delivery of tb-planning to me, so I never saw this 

I've expressed most of these thoughts in various discussions before, so apologies for the repetition.

Binary linkage with silent update releases more or less every 6 weeks is a huge challenge. So, as you say, the only way Skink would be usable is if it's shipped with the 
core product.

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.

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.

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.

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.

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.
    * Adapt Skinkglue to deal with pluggable stores and try to make the pluggable store code lessen the need for workarounds in Skinkglue
    * Some sort of unit tests (e.g., tweequilla)

- David

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

More information about the tb-planning mailing list