New Account Types directions - should SkinkGlue be core?

Kent James 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 
problem.

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 
monetization.

> 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 
reimplement the standard features in javascript, and
3) a standard implementation is needed but missing for certain capabilities.

Problem 3) does not occur in addressbook. SkinkGlue provides a solution 
to 2), a javascript-accessible way to extend the standard nsIAbDirectory 
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 
new address book implementations in pure javascript that do not require 
SkinkGlue.

A really fundamental question is, do you want to have base C++ objects 
that are extendable both using javascript and C++ code? If yes, do you 
want to use the msqIOverridable interface of SkinkGlue, or some other 
approach? Or is the long-term plan to rewrite the entire mailnews 
infrastructure in javascript? Until these meta issues are addressed, it 
is hard to know what refactoring should be done of core interfaces.
> Thanks for your hard work and your commitment,
>
> jonathan
And the same to you. I especially appreciate your efforts to try to 
create direction, teamwork and camaraderie in the project.

rkent



More information about the tb-planning mailing list