New Account Types directions - should SkinkGlue be core?
kent at caspia.com
Thu May 12 21:04:54 UTC 2011
On 5/12/2011 7:46 AM, Jonathan Protzenko wrote:
> There's a little bit of vacancy right now in terms of management, as the
> team is reintegrating Mozilla, which probably doesn't help you get
> strong commitments towards merging this into the main product.
This "little bit of vacancy" has been going on for much longer than the
current reintegrating process, really since about the time when TB 3.0
was released. Thunderbird really, really needs someone to fill the
product management role.
> - there is a lot of machinery involved, and this will probably make
> adding new account types really hard unless the person is familiar with
> writing Thunderbird code
This is true. But a sample like TweeQuilla was intended to be show the
way. It is not SkinkGlue that is complex, it is the underlying
interfaces and component definitions.
> - however, doing a full rewrite of the interfaces is not applicable, as
> we're far from having the required workforce for this.
The key interfaces (nsIMsgDBHdr, nsIMsgFolder, nsIMsgIncomingServer,
etc.) have way too many methods, many not scriptable, to be really
easily duplicated for a new account. It would be helpful if there was a
commitment to an overall direction to improve that. Just as a small
example, nsIMsgDatabase has lots of noscript method with parameters that
in C++ are implemented as TArrays. Is there a desire to change that? Not
clear. If I were to propose simplifications, though I could probably get
them approved, but I feel like they would be accepted reluctantly to
support my personal projects, rather than recognized as valued
contributions to the direction of Thunderbird. Maybe this is just my
At some point there was a commitment made to de-rdf the code, and to
support external linkage. While neither of those has been completed, at
least there has been significant motion in that direction (and I need
and use the external linkage version of core objects in SkinkGlue). We
need more architectural directives like that.
> Assuming (and this all depends on the orientation that the future
> product manager for Thunderbird will choose) we continue into this
> direction, I think we should merge SkinkGlue
I was actually considering doing a short post to summarize my
conclusions from this thread, which were that there is not sufficient
interest to justify attempting to integrate SkinkGlue at this point in
time. That however means that for all practical purposes, I am the only
one who will maintain a capability to add new account types to
Thunderbird for the foreseeable future.
> and have you commit to
> providing both Exchange support and Twitter support for Thunderbird, as
> "official extensions".
I was looking for more than some variation of "if you will take full
responsibility for this, and agree in addition to do such-and-such, then
we will accept your work." There is a sense of teamwork and camaraderie
that is missing from the Thunderbird project and efforts such as my own.
Maybe this is mostly my fault, as I have never really been comfortable
in the role of volunteer in a staff-driven project. But without some
sort of team effort to extend Thunderbird with new account types, if
this is just going to be my work, then it is easier and more profitable
for me to just do it on my own.
> When we feel they're ready, we might even / should integrate them.
Given my comments on monetization, an approach that I would prefer and
have proposed is to somehow make extensions more central to the way that
Thunderbird is shipped, and allow extension authors a clearer path to
> If I understood well, this also provides a nice abstraction layer for
> implementing new address book types. Could you please explain how does
> that relate to mconley's work on de-RDFing address book? Is your skink
> glue compatibility layer still required? Can we get rid of it? I'm
> thinking about broader commitment to rewriting the address which I feel,
> unlike rewriting the other interfaces that you fix with skinkglue, is
> within reach.
SkinkGlue addresses three connected but independent problems:
1) various non-scriptable interface features require C++ solutions, and
2) new account types should really extend existing standard
implementations (nsMsgDBFolder, nsMsgIncomingServer, etc.) rather than
3) a standard implementation is needed but missing for certain capabilities.
Problem 3) does not occur in addressbook. SkinkGlue provides a solution
base implementations in nsRDFResource and nsAbDirProperty, just like the
C++ accounts do. mconley's work should resolve 1), but it is still
convenient to use the SkinkGlue nsIAbDirectory implementation to allow
use of the base nsAbDirProperty implementation.But nobody would do that
unless they are already using SkinkGlue, so his work should allow easier
A really fundamental question is, do you want to have base C++ objects
want to use the msqIOverridable interface of SkinkGlue, or some other
approach? Or is the long-term plan to rewrite the entire mailnews
is hard to know what refactoring should be done of core interfaces.
> Thanks for your hard work and your commitment,
And the same to you. I especially appreciate your efforts to try to
create direction, teamwork and camaraderie in the project.
More information about the tb-planning