<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 6/2/2011 10:40 AM, David Bienvenu wrote:
<blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<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>
</blockquote>
(Just to be clear, in my terminology "Skink" is the ugly set of
interfaces that I have to deal with in the core code. I'll rename
those to "Swan" when and if they become pretty ;) )<br>
<br>
I am encouraged to see a pretty clear commitment from you that
cleaning up these interfaces to better support js is valuable.
You've probably thought that for awhile, but occasional comments
from you (like a recent hesitation to remove the TArray db methods)
left me in doubt. It's much harder for me to get motivated to work
on things that I think will be only accepted reluctantly, than
things that are really wanted.<br>
<blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite"> <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>
</blockquote>
Looking forward to seeing that land.<br>
<blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite"> <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.</blockquote>
It's a really important issue, whether or not new data sources
appear enough like the older sources so that all of the standard UI
bells and whistles can work with them. I'm thinking of things like
tagging, marking as read, combining into virtual folders with mail
items, filtering, threading, grouped headers, etc. You could always
just include <a class="moz-txt-link-freetext" href="http://twitter.com">http://twitter.com</a> in a tab, and call that "Twitter
support" - but that is not really what we are talking about here.<br>
<br>
Something that I use with TweeQuilla for example is "Starring"
tweets, and then displaying them along with mailnews items in a
single Starred virtual folder that represent items that I need to
followup.<br>
<br>
My own vision is that a messaging client needs to be able to include
as much as possible a set of standard features that are supported
across a wide variety of data sources - and yet there still needs to
be unique differences for each. So I think that the main point would
be lost if new data items could not easily play with the existing
infrastructure (and by that I mean user-facing issues like tagging,
not nsIMsgDBHdr).<br>
<br>
These are really important questions that I think we should be
discussing here rather than what seems to get lots of interest. We
suffer from the "color of the bike shed" problem sometimes. <br>
<br>
<blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite"> 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>
</blockquote>
I would say actually that another "main drawback" is the need to use
a C++ - based implementation as prototypes for js objects.<br>
<br>
So really SkinkGlue does these four things:<br>
<br>
1) provides workarounds and interface implementations for
non-scriptable interfaces.<br>
2) implements common functions such as folder discovery and database
creation<br>
3) solves certain issues that are not handled properly in xpconnect
(like the issue of returning null pointers as out items)<br>
4) provides a mechanism to use and selectively override the existing
standard object implementions of things like nsMsgDBFolder and
nsMsgIncomingServer.<br>
<br>
1) and 3) are solvable through code cleanup.<br>
<br>
You say that 2) is at least partly handled by the pluggable store
code.<br>
<br>
4) though is still an important issue.<br>
<br>
To have any hope of new data items reliably supporting an existing
robust infrastructure, then the data items need to be able to
inherit from an existing implementation of things like servers,
folders and items. A key question is whether in the foreseeable
future Thunderbird will provide js language versions of those things
(like Calendar's ProviderBase for example). If not, does each new
data source implement their own, or will something like the
msqIOverridable interface be provided to allow using the existing
C++ prototypes? This issue you have not really addressed.<br>
<br>
<blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite"> <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>
</ul>
</blockquote>
Is it fair to say that there is a general commitment to the idea of
solving the issues that SkinkGlue has identified in the core code,
to move closer to allowing creating of new data items with
javascript implementations?<br>
<blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite">
<ul>
<li>Adapt Skinkglue to deal with pluggable stores and try to
make the pluggable store code lessen the need for workarounds
in Skinkglue</li>
</ul>
</blockquote>
My existing Exchange data types derive from the C++ SkinkGlue
objects, so I will be continuing to adapt it to changes in the core
code. Suggestions would be more than welcome here.<br>
<blockquote cite="mid:4DE7CB25.7050209@mozilla.com" type="cite">
<ul>
<li>Some sort of unit tests (e.g., tweequilla)</li>
</ul>
</blockquote>
Just as nsMsgDBFolder does not really have unit tests, SkinkGlue's
tests ideally would be an implementation of a particular data type
that has its own tests. My Exchange Server extension has some basic
unit tests in it for example that exercises SKinkGlue (though by no
means exhaustively).<br>
<br>
rkent<br>
</body>
</html>