Talk:Thunderbird:Thunderbird3: Difference between revisions
| Line 45: | Line 45: | ||
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. | 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. Anonymous | 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. Anonymous | ||
I suggest you add a lower level goal of providing a help system, to help meet the high level goal of | I suggest you add a lower level goal of '''providing a help system''', to help meet the high level goal of | ||
To improve usability". See http://interimhelp4tbird.mozdev.org/ [[User:Tanstaafl|Tanstaafl]] 19:46, 24 March 2008 (PDT) | To improve usability". See http://interimhelp4tbird.mozdev.org/ [[User:Tanstaafl|Tanstaafl]] 19:46, 24 March 2008 (PDT) | ||
| Line 55: | Line 55: | ||
* Lots of people add comments in the appropriate planning documents talk page lobbying for certain features. When the next major release is released we all scratch our heads trying to figure out why certain features were implemented, and whether there is a chance that what we wanted will get implemented in the next release. It would help if you publish a one page document describing the criteria you use to determine what to add/implement for each major release beforehand, and afterwards provide a short document listing the top 30 features that were considered, showing how they were ranked/scored, and where the dividing line was. This wouldn't take much time, and might help provide more useful input from users next time. [[User:Tanstaafl|Tanstaafl]] 19:46, 24 March 2008 (PDT) | * Lots of people add comments in the appropriate planning documents talk page lobbying for certain features. When the next major release is released we all scratch our heads trying to figure out why certain features were implemented, and whether there is a chance that what we wanted will get implemented in the next release. It would help if you publish a one page document describing the criteria you use to determine what to add/implement for each major release beforehand, and afterwards provide a short document listing the top 30 features that were considered, showing how they were ranked/scored, and where the dividing line was. This wouldn't take much time, and might help provide more useful input from users next time. [[User:Tanstaafl|Tanstaafl]] 19:46, 24 March 2008 (PDT) | ||
Allow for '''completely hiding the folder pane'''. The folder pane is only needed when switching between folders. But switching between folders could be easily be done through a popup box (as in SeaMonkey). This would allow for a dual pane instead of the usual triple pane layout, occupying much less screen area. | |||
Revision as of 14:39, 27 May 2008
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
As an extension developer, one thing that frustrates me is that some key functionality is not exposed to extensions. For example, deleting messages seems to be handled without JS exposure, and some areas of composing messages, specifically reply-all functionality, is likewise not exposed or broken. It would be great to expose more to the extensions. --Watusimoto
reply: These are exactly the kinds of problems Steel is aiming to solve. If all goes according to plan, extensions will have this functionality exposed in TB3. --jminta
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)
- I refer to comment 75 of bug 58308. Or comment 18 of bug 290057. Just search bugzilla for maildir --GustB 04:58, 7 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)
Another group of problems is the MIME handling, summarized in Fix some longstanding bugs. Certain highly visible bugs related to MIME-type parsing (e.g., with quoted-printable HTML messages) and attachment handling (management of Content-Type associations and actions) should be addressed, a comment in one of the bugs suggests a major overhaul of the MIME module code. --Rsx11m 14:34, 2 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)
- I've expanded on this in Talk:Thunderbird:Easy Account Setup. --Rsx11m 12:20, 9 March 2008 (PDT)
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)
A link to the Thunderbird:Fix some longstanding bugs article should be provided in addition to Thunderbird:Thunderbird 3 Possible Bugs as all of those are probably likely candidates for priority fixes. --Rsx11m 14:58, 2 March 2008 (PST)
I'd like to try out TB3 to see how it's UI looks like, yet I can't afford loosing any mails (not even already read ones). It would be nice if there's a "read-only" mode during installation or running.
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. Anonymous
I suggest you add a lower level goal of providing a help system, to help meet the high level goal of To improve usability". See http://interimhelp4tbird.mozdev.org/ Tanstaafl 19:46, 24 March 2008 (PDT)
None of the goals address process issues. Or perhaps I should say helping to get users more involved.
- Its quite common to have bugs sit for years as new or unconfirmed with no assignment to a developer, let alone a comment by one, and then sometimes be closed automatically for inactivity. This discourages users from filing bug reports. As an aside telling somebody "Also, please do not file bugs on browser/email software older than two weeks - first, download a newer build of Firefox, Thunderbird, SeaMonkey, or Camino and check that the problem is still present." who only uses released versions doesn't exactly make them feel welcome.
- Lots of people add comments in the appropriate planning documents talk page lobbying for certain features. When the next major release is released we all scratch our heads trying to figure out why certain features were implemented, and whether there is a chance that what we wanted will get implemented in the next release. It would help if you publish a one page document describing the criteria you use to determine what to add/implement for each major release beforehand, and afterwards provide a short document listing the top 30 features that were considered, showing how they were ranked/scored, and where the dividing line was. This wouldn't take much time, and might help provide more useful input from users next time. Tanstaafl 19:46, 24 March 2008 (PDT)
Allow for completely hiding the folder pane. The folder pane is only needed when switching between folders. But switching between folders could be easily be done through a popup box (as in SeaMonkey). This would allow for a dual pane instead of the usual triple pane layout, occupying much less screen area.