<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
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 thread.<br>
<br>
I've expressed most of these thoughts in various discussions before,
so apologies for the repetition.<br>
<br>
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 core product.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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.<br>
<br>
The path for Skinkglue getting into core would look something like
this:<br>
<br>
<ul>
<li>Fix the core interfaces wherever practical to be scriptable so
that Skinkglue an be simplified.</li>
<li>Adapt Skinkglue to deal with pluggable stores and try to make
the pluggable store code lessen the need for workarounds in
Skinkglue</li>
<li>Some sort of unit tests (e.g., tweequilla)</li>
</ul>
<br>
- David<br>
<br>
<br>
</body>
</html>