Re: New Account Types directions - should SkinkGlue be core?
8 views
Skip to first unread message
David Bienvenu
Jun 2, 2011, 1:40:53 PM6/2/11
to tb-pl...@mozilla.org, Kent James
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.
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 core product.
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:
- David
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 core product.
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)
- David
Kent James
Jun 3, 2011, 2:29:50 AM6/3/11
to tb-pl...@mozilla.org
On 6/2/2011 10:40 AM, David Bienvenu wrote:
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.
(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 ;) )
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.
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.
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.
Looking forward to seeing that land.
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.
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 http://twitter.com in a tab, and call that "Twitter
support" - but that is not really what we are talking about here.
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.
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).
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.
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.
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).
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.
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.
I would say actually that another "main drawback" is the need to use
a C++ - based implementation as prototypes for js objects.
So really SkinkGlue does these four things:
1) provides workarounds and interface implementations for non-scriptable interfaces.
2) implements common functions such as folder discovery and database creation
3) solves certain issues that are not handled properly in xpconnect (like the issue of returning null pointers as out items)
4) provides a mechanism to use and selectively override the existing standard object implementions of things like nsMsgDBFolder and nsMsgIncomingServer.
1) and 3) are solvable through code cleanup.
You say that 2) is at least partly handled by the pluggable store code.
4) though is still an important issue.
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.
So really SkinkGlue does these four things:
1) provides workarounds and interface implementations for non-scriptable interfaces.
2) implements common functions such as folder discovery and database creation
3) solves certain issues that are not handled properly in xpconnect (like the issue of returning null pointers as out items)
4) provides a mechanism to use and selectively override the existing standard object implementions of things like nsMsgDBFolder and nsMsgIncomingServer.
1) and 3) are solvable through code cleanup.
You say that 2) is at least partly handled by the pluggable store code.
4) though is still an important issue.
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.
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.
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?
- Adapt Skinkglue to deal with pluggable stores and try to make the pluggable store code lessen the need for workarounds in Skinkglue
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.
- Some sort of unit tests (e.g., tweequilla)
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).
rkent
rkent
Robert Kaiser
Jun 3, 2011, 7:37:52 AM6/3/11
to tb-pl...@mozilla.org
David Bienvenu schrieb:
> 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.
> 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.
If Thunderbird is serious about the basic idea that was behind
Netscape's and Mozilla's MailNews module from the beginning, then all
message sources should be in a UI that is as unified as possible while
providing most of the specific upsides of each as well.
Right now, that's most the case, though Thunderbird is as I understand
falling apart visually at times due to the new experiments like faceted
search etc. not fitting the style of the rest of the UI as smoothly as a
UI designer would want it to be.
I think what Thunderbird would need is to have all, including the
traditional, message types go through scriptable and more lightweight
and pluggable interfaces.
(I personally also think that ultimately, Thunderbird needs to be able
to run integrated within Firefox if it wants to survive, but that might
just be myself dreaming things up.)
Robert Kaiser
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Kent James
Jun 3, 2011, 10:57:47 AM6/3/11
to tb-pl...@mozilla.org
On 6/3/2011 4:37 AM, Robert Kaiser wrote:
(I personally also think that ultimately, Thunderbird needs to be able to run integrated within Firefox if it wants to survive, but that might just be myself dreaming things up.)
I'm with you here. When the Thunderbird grows up and becomes a Swan,
then we will have SwanFox as the integration.
Ever since I wrote "Lessons from Google: Thunderbird as a Firefox extension!" I've been convinced that is the correct strategy. Any cat herders out there able to organize us in this direction?
rkent
Ever since I wrote "Lessons from Google: Thunderbird as a Firefox extension!" I've been convinced that is the correct strategy. Any cat herders out there able to organize us in this direction?
rkent
David Bienvenu
Jun 3, 2011, 1:18:28 PM6/3/11
to tb-pl...@mozilla.org
On 6/2/2011 11:29 PM, Kent James wrote:
On 6/2/2011 10:40 AM, David Bienvenu wrote: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.
I don't remember that discussion, to be honest. I don't want to
remove those methods, but I'd be happy to replace them with
nsIMutableArrays or the like. I do remember not wanting to remove
nsIURI return values for some methods but that was an discussion
about how to make the methods compatible with Skinkglue, not whether
to.
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 http://twitter.com in a tab, and call that "Twitter support" - but that is not really what we are talking about here.
It depends on the user and the data source. I'd be happy with a UI
that lets me easily save an individual tweet into a folder but lets
me read them in batches as a stream and doesn't require me to mark
them read or god forbid, read them one at a time. Tweets are by
default ephemeral, which is different (usually) from my e-mail.
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).
I'm not disagreeing - I'm saying there are some data sources where
it's much less important. That's not the same as saying there aren't
data sources where it is important. Obviously there are...
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.
Providing js versions of those objects is definitely something we'd
like to do. But it would involve a complete redesign of the
interfaces; they're extremely unwieldy. There's an obvious tension
between a desire to throw away the current interfaces and start
over, or to make it possible to implement the current interfaces in
js soon.
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?
yes, that's highly desirable.
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.
Pluggable stores in the context of remote servers like IMAP or
Exchange really just affects offline storage and offline folder
discovery. I'm guessing that you don't need to do much to adapt to
pluggable stores, if you're using the base classes (e.g.,
nsMsgDBFolder::GetOfflineStoreInput/OutputStream) and pattern your
code somewhat after the IMAP code. But I'm happy answer any
questions you have about it.
- David
- David
Andrew Sutherland
Jun 3, 2011, 1:24:34 PM6/3/11
to tb-pl...@mozilla.org
The gecko platform needs to advance a bit more in the
multi-process/multi-thread direction before this becomes feasible.
Dumping the Thunderbird main thread activities on the already taxed
Firefox main thread would worsen the experience for both use-cases.
Andrew
Andrew
Robert Kaiser
Jun 3, 2011, 11:25:17 AM6/3/11
to Kent James, tb-pl...@mozilla.org
Kent James schrieb:
> On 6/3/2011 4:37 AM, Robert Kaiser wrote:
>> (I personally also think that ultimately, Thunderbird needs to be able
>> to run integrated within Firefox if it wants to survive, but that
>> might just be myself dreaming things up.)
> I'm with you here. When the Thunderbird grows up and becomes a Swan,
> then we will have SwanFox as the integration.
>
> Ever since I wrote "Lessons from Google: Thunderbird as a Firefox
> extension!"
> <http://mesquilla.com/2010/06/01/lessons-from-google-thunderbird-as-a-firefox-extension/>
> I've been convinced that is the correct strategy. Any cat herders out
> there able to organize us in this direction?
> On 6/3/2011 4:37 AM, Robert Kaiser wrote:
>> (I personally also think that ultimately, Thunderbird needs to be able
>> to run integrated within Firefox if it wants to survive, but that
>> might just be myself dreaming things up.)
> I'm with you here. When the Thunderbird grows up and becomes a Swan,
> then we will have SwanFox as the integration.
>
> Ever since I wrote "Lessons from Google: Thunderbird as a Firefox
> extension!"
> I've been convinced that is the correct strategy. Any cat herders out
> there able to organize us in this direction?
My "RMD" idea - http://wiki.kairo.at/wiki/RMD - was my try to get some
infrastructure up that could support that, basically by getting a
completely new in-tab Firefox add-on UI and organizational system into
place that would base on pluggable modules. It would be defined
primarily around web-based messaging systems like feeds and
twitter/status.net (using so different schemes is intentional) for
starting experimentation, but keep in mind that it should be extendable
to potentially support traditional as well as not-yet-invented messaging
systems as well. It would run completely in the browser, be able to use
app tabs, yadda, yadda.
Yes, this would be a complete interface rewrite, taking lessons from the
current mailnews UI into account, potentially reusing some good pieces
of code, but not fearing to build stuff really differently.
This might be something for an independent add-on dev, for Mozilla Labs,
or whatever - I didn't manage to get it into GSoC due to Mozilla having
limited slots (we had 3-4 students wanting to take it, though) and I
don't have the time to work on an actual implementation myself. Also,
I'm better in doing concepts than writing code. ;-)
Still, this all leads far away from the actual topic of the thread, I
guess, and potentially even from what this list is for - though
messaging people are now a part of Labs... ;-)
Tanstaafl
Jun 3, 2011, 11:37:38 AM6/3/11
to tb-pl...@mozilla.org
On 2011-06-03 10:57 AM, Kent James wrote:
> On 6/3/2011 4:37 AM, Robert Kaiser wrote:
>> (I personally also think that ultimately, Thunderbird needs to be able
>> to run integrated within Firefox if it wants to survive, but that
>> might just be myself dreaming things up.)
> On 6/3/2011 4:37 AM, Robert Kaiser wrote:
>> (I personally also think that ultimately, Thunderbird needs to be able
>> to run integrated within Firefox if it wants to survive, but that
>> might just be myself dreaming things up.)
> I'm with you here. When the Thunderbird grows up and becomes a Swan,
> then we will have SwanFox as the integration.
>
> Ever since I wrote "Lessons from Google: Thunderbird as a Firefox
> extension!"
> <http://mesquilla.com/2010/06/01/lessons-from-google-thunderbird-as-a-firefox-extension/>
> I've been convinced that is the correct strategy. Any cat herders out
> there able to organize us in this direction?
<sigh> Please don't - or at least, it should be optional...
If I wanted to use SeaMonkey (or Opera), I'd use SeaMonkey (or Opera).
Reply all
Reply to author
Forward
0 new messages