Talk:Thunderbird:Thunderbird3

Comments on 'Better Extensibility'

Personally, I think it'd be better to simply point tb extension developers at #maildev on IRC. There's so much that can be learned just by reading scrollback, and splitting up the mail-expertise and mail-scrollback would seem like a loss to me. Also, splitting channels makes it less likely that someone will be around to answer a question in either channel, which just leads to frustration. --jminta

Sounds good. I've adjusted the copy. --davida

Comments on 'Architectural cleanup'

I know some people don't share my love of JavaScript, but I'd like to see the architectural cleanup include an audit of mail components for possible candidates to move from C++ to JS. Firefox has gone this route for components not on perf-critical paths, for example the search service or the download manager. Advantages include virtually crash-proof code and no reference counting. Also, it seems as though Mozilla2 will be moving even more things to JavaScript (with ES4), so getting a head-start on this would be good. --jminta

I'm not sure if it has been mentioned elsewhere, but the move away from mork for the .msf files seems to be a good opportunity to dump mbox as well (and replace it by maildir). It occurs to me that common agreement was already reached on this issue, which is tracked in bug 58308. As a placeholder I've added it here--GustB 12:46, 4 February 2008 (PST)

Its not clear to me that "common agreement" was reached on replacing mbox with maildir. I periodically see a few posts in the mozillaZine forums from people asking for this, but most users have no idea what it even is because they are using Windows. Many of the comments in the bug report advocate supporting both formats. Tanstaafl 09:33, 2 March 2008 (PST)

Is the de-morkification the first of a two step process, where its changes eventually get replaced by Unified Storage? Tanstaafl 09:33, 2 March 2008 (PST)

A common problem that I see in the mozillaZine forums is users panicking due to Thunderbird appearing to lose all of their data the next time they start it. There are arguments whether this is mainly due to prefs.js getting corrupted or a old bug where Thunderbird sometimes forgets about the existence of a profile in profiles.ini but I'm surprised some minor architectural changes to work around this issue weren't considered. Tanstaafl 14:33, 1 March 2008 (PST)

Comments on 'Increased Adoption'

The item 'GMail IMAP support' can probably be a subpoint under 'Simple Account Setup', as it is an example of an ISP-specific setup. My concern here is that it would involve a lot of work to cover all possible ISP setups across the world, not to mention non-public corporate or institutional setups. Thus, equal effort should be given to the extension of the Account Wizard to allow alternate encryption and port settings to be entered already during the initial setup. A partial patch is pending review for more than two years now in bug 221030. --Rsx11m 21:13, 24 February 2008 (PST)

Comments on 'Getting Involved'

You mention that there are currently 1300+ RFE's for Thunderbird pending, this does not include some 800+ RFE's for the MailNews Core modules. About 120+ (total) of those RFE's have at least partial patches up for review, thus would be easier to add than others. It may be worth to go through those to determine which ones fit into the concepts for TB3, and to give them some increased priority. --Rsx11m 21:21, 24 February 2008 (PST)

Goals of the Thunderbird 3

IMO people don't want to get yet another mailer, people want to get a modern communication center which handles all kind of personal information. This essentially means a TB3 has to be able to synchronize these information to any kind of external storage (devices). It has to be realized that synchronization will become the main data exchange protocol anytime in the future and might even supplant POP3/IMAP/SMTP later on. Therefore it's essential to plan to base the internal structure on e.g. SyncML (OpenSync) and move the older protocols into addable/removable plugins. This would allow to open up TB3 for future uses which aren't known so far. Besides TB3 would get a simple internal structure to handle all currently known whishes.

So first action should be to add synchronization to the goals of TB3. The second action should be to analyze OpenSync and determine how feasible it is as the base of TB3. Third action should be to define the necessary APIs of the needed plugins, e.g. check if access to SQLite could be realized as a plugin and used as the information storage engine. A concept of this kind probably is robust enough to handle many more whishes without making it more complex. Many if not most wishes might simply be realized in an appropriate plugin.