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

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.