New Account Types directions - should SkinkGlue be core?
dbienvenu at mozilla.com
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
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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning