New Account Types directions - should SkinkGlue be core?
Pidgeot18 at verizon.net
Thu May 12 21:56:17 UTC 2011
On 05/12/2011 05:04 PM, Kent James wrote:
> 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?
About 3.5 years ago, when I first attempted synthesizing new account
types, I intended to reimplement most/all of the interfaces from
scratch. I gave up on that approach by the end of that summer as being
too hard, since you would be endlessly trying to port the fixes to
nsMsgDBFolder (89 as counted from comm-central in my build). Not least
of which is probably the performance hit that would come from
implementing nsMsgDatabase in JS.
> 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.
Simplifying those interfaces is probably a win-win situation. After all,
should I use prettyName or prettiestName? ;-)
> 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.
I think the real fear here is that mailnews would be left with yet
another "not really used, mostly unmaintained component that we are
still obligated to fix anytime something breaks" (think about the old
palmsync code, or even (arguably) movemail). The other fault that I can
see is the fact that the userbase of Thunderbird is largely a
conservative bunch that react very noisily to ambitious changes.
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
More information about the tb-planning