A Thunderbird "stdlib"

Andrew Sutherland asutherland at asutherland.org
Fri Dec 17 09:13:23 UTC 2010

On 12/16/2010 01:13 PM, Jonathan Protzenko wrote:
> I don't feel like this is worth integrating into the tree. However, 
> what if I spun off these "common parts" into a separate github repo 
> and we started advertising it as a "readymade" package that extension 
> authors can include in their own builds, to make their lives easier? I 
> feel like that's exactly the kind of stuff I missed when I was 
> starting...

This sounds like a good idea to me.  This is roughly how the Add-on 
SDK/Jetpack does things; every extension built with Jetpack includes its 
own copy of Jetpack and any libraries.

As an elaboration of agreement, I think Python has a good model for 
these kinds of things.  Some things have to be in the core, but a lot of 
things do not, especially libraries.  It can be useful to move libraries 
into the core, but they should have reached a stable API point because 
evolving them once they've moved into the core can be problematic.

Continuing the Python example, the need for moving things into the core 
library greatly decreases with a good package management system.  I have 
to concede that non-Jetpack extensions do not have this provided to them 
on a platter, but as long as the github repo is structured so that you 
can easily check it out into a subdir of an extension, that should not 
actually pose a problem.

Specifically, I could structure my extension so that I check out 
"tb-stdlib" into "content/modules" of my extension if tb-stdlib keeps 
things in the root.  (Or maybe the .gitmodules mechanism lets you check 
out a subdir of a repo?  I don't have enough experience with it yet.)

Once things are stabilized and if they have tons of unit tests, it could 
make sense to move things into the core.  In this specific case, since 
the abstractions all operate at the nsIMsgDBHdr, I would suggest we 
don't migrate the library into core just because I don't think we want 
that to be part of our official/supported/friendly API substrate.


More information about the tb-planning mailing list