Thunderbird 3 Planning
David Ascher
time learning about the state of affairs and talking to many people, and
I feel I've accumulated enough information to start this process.
Note: I'm cross-posting this to the planning, calendar and thunderbird
newsgroups, but expect discussion on the thunderbird newsgroup and have
set followup-to accordingly. There will be a summary post in the
planning newsgroup if the final plan differs significantly from the one
outlined here.
The long-term roadmap of Thunderbird is still in flux, but there are
four high-level points which drive my thinking about Thunderbird 3:
1. Thunderbird's impact is proportional to its user count. Thus driving
adoption is my primary concern. Our current user base is very
significant (many millions of mostly quite satisfied users), but the
number of possible users of Thunderbird is orders of magnitude greater
than our current reach.
2. The reasons why people don't choose to use Thunderbird are varied,
but two primary reasons appear to be: the lack of a built-in calendar
integration (compared to Outlook for example), or a search experience
that doesn't match that offered by competitors (gmail and Mail.app for
example).
3. In addition, Thunderbird's codebase has a fair bit of technical debt
due to insufficient resourcing over the years, which has led to a
codebase which has too many scary bits, not enough test coverage, and
isn't yet able to leverage the ongoing platform improvements. In
addition, while communications clients are by nature great targets for
extension authors, the current codebase isn't extension-friendly enough,
making it too hard to build installation-specific features or experiment
with new feature ideas.
4. A fair number of Thunderbird changes have already landed on trunk,
including some important bug fixes, by a variety of contributors.
There's appropriate pressure to ship an update to Thunderbird 2 to take
advantage of those and of the platform improvements.
With all that as background, I propose:
* Goal: to have at public milestone build of Thunderbird 3 in 2008.
Thunderbird 3's overall aim is to significantly grow its user base
worldwide, as well as build a strong foundation for later Thunderbird
releases.
* Release-defining features:
- an integrated calendaring feature, based on Lightning
- a better search experience, especially for message content searches
- a better overall user experience
* Less user-visible but important goals include:
- Significant headway on getting rid of Mork and RDF
- A concerted effort to improving the extensions ecosystem for
Thunderbird, including refactorings, FUEL, developer documentation, and
user experience
- Better test coverage and performance metrics in place to support
refactoring goals
There will be of course lots of other bug fixes and enhancements
(patches welcome ;-))
* Schedule: Figuring out the schedule at this stage is hard, as it will
depend on who shows up with energy and talent. I would like to set some
placeholder milestones for discussion, however:
- alpha builds in Q1
- beta builds without calendaring starting in Q2
- beta builds with calendaring starting in Q3
- widely useful builds by Q4 (although whether they're branded
"release" will depend on quality, as always).
We're revise the schedule as we gain knowledge.
* Thunderbird 3 work will happen on trunk, with branching strategy to be
figured out closer to the endgame (and reviewed next when 1.9 is cut),
* The Mailnews/Thunderbird folks and the Calendar folks will have to
figure out how to best allocate dev and testing effort on the
calendaring features, how we support Sunbird, etc.
Given the scope of the work, the aggressive schedule, and the amount of
new feature develoment, integration and stabilization work involved,
help of all kinds is more than welcome! Thanks in advance for any input
you may have, either on process or on deliverables.
The central wiki page for Thunderbird 3 is
http://wiki.mozilla.org/Thunderbird:Thunderbird3. IRC discussion will
take place in #maildev. The newsgroup/mailing list of record for Tb3 is
mozilla.dev.apps.thunderbird.
I look forward to the discussion!
-- David Ascher
Eddy Nigg (StartCom Ltd.)
This plan looks to me overall as modest and doable, with the right set
of priorities to prepare for future and bolder goals and aims. Perhaps
the time line could be squeezed a little bit in order to have a release
in 2008, considering that Lightning has improved quite a bit lately.
However the plan looks realistic and serious to me.
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>
Sergey Yanovich
> With all that as background, I propose:
>
> * Goal: to have at public milestone build of Thunderbird 3 in 2008.
> Thunderbird 3's overall aim is to significantly grow its user base
> worldwide, as well as build a strong foundation for later Thunderbird
> releases.
>
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
> - a better search experience, especially for message content searches
> - a better overall user experience
>
> * Less user-visible but important goals include:
> - Significant headway on getting rid of Mork and RDF
> - A concerted effort to improving the extensions ecosystem for
> Thunderbird, including refactorings, FUEL, developer documentation, and
> user experience
> - Better test coverage and performance metrics in place to support
> refactoring goals
>
> There will be of course lots of other bug fixes and enhancements
> (patches welcome ;-))
This may also be cool:
* Improved administrator experience:
- MSI;
- Group Policy Options.
There is a thread 'Firefox for Corporations' in m.d.platform, which
fully applies to Thunderbird. Please check bug 231062 for MSI patches :)
--
Sergey Yanovich
Gary Kwong
> - beta builds without calendaring starting in Q2
> - beta builds with calendaring starting in Q3
> - widely useful builds by Q4 (although whether they're branded "release"
> will depend on quality, as always).
That will also depend on the timeframe that Calendar hits 1.0, though I
think it's projected for 2008 as well.
I'm of the opinion that the first beta should have already included
Lightning if it's one of the main pillars of the Thunderbird 3 release.
What's the point of calling it a beta when one of the main backbone
features is not present?
I am leaning towards the possibility of including Lightning 0.9 in an
Alpha / Beta 1 build, as a form of "dress rehearsal" for 1.0.
>
> * The Mailnews/Thunderbird folks and the Calendar folks will have to
> figure out how to best allocate dev and testing effort on the
> calendaring features, how we support Sunbird, etc.
There's substantial code that overlaps with Lightning, and also there's
code that doesn't. If 100% of Lightning's tested to work fine, chances
are that 60%++ of Sunbird already works well, the other 40% being
non-overlapping stuff. (something to keep in mind for QA)
Gary Kwong
David Ascher
> This may also be cool:
> * Improved administrator experience:
> - MSI;
> - Group Policy Options.
>
>
> There is a thread 'Firefox for Corporations' in m.d.platform, which
> fully applies to Thunderbird. Please check bug 231062 for MSI patches :
various "enterprise" requirements. In addition to MSI and Group Policy
issues, there are update management issues, as well as UI-limiting ideas
like those outlined in bug 414301.
We should discuss this on the community-enterprise list, however -- I'm
still trying to figure out how many sub-communities there are trying to
tackle organizational deployments of Thunderbird, and which of the
requirements are highest priority.
--david
Myk Melez
> It's time to define the Thunderbird 3 plan. I've spent a fair bit of
> time learning about the state of affairs and talking to many people, and
> I feel I've accumulated enough information to start this process.
To me this looks like a great plan, appropriately scoped but with real
and significant progress and promise for Thunderbird futures. I second
Eddy's desire for a final release this year, but my reading of your
proposal is that it plans for exactly that outcome, just with a bit of
hedging given the difficulty of making that prediction and the desire
for a quality- rather than merely date-driven release.
-myk
David Ascher
I'm very keen to see a public release in 2008. But it's a foolish dev
manager who sets scope and schedule with absolutely no visibility on
available resources =)
While adding people to a late project makes it later, having too few
hands on keyboards makes it hard to produce good releases -- there's a
careful balance to be found.
My plan is to focus on getting as many bright people interested in
working on it as soon as possible, and with enough planning, enthusiasm,
luck, and the right discipline regarding scope creep, we may just get
there...
--david
JoeS
Ah.. regarding quality, might we address the issue of core code changes that affect apps like thunderbird.
Since https://bugzilla.mozilla.org/show_bug.cgi?id=385740 which was a great change for Firefox myk, the trunk
for Tbird was severely impacted. If you save an action, as far as opening a link or calling a helper app, there
is absolutely no way to edit that pref. Apart from saving your mimeTypes.rdf (or a null version of same) you are
stuck with your decision.
These things are constantly cropping up, some serious, some not.
https://bugzilla.mozilla.org/show_bug.cgi?id=413200 has lingered now for a week or so.
-- JoeS
Eddy Nigg (StartCom Ltd.)
> These things are constantly cropping up, some serious, some not.
> https://bugzilla.mozilla.org/show_bug.cgi?id=413200 has lingered now for a week or so.
>
>
"lingering" ;-) I guess your expectations are quite high...
Myk Melez
> Since https://bugzilla.mozilla.org/show_bug.cgi?id=385740 which was a
> great change for Firefox myk, the trunk
> for Tbird was severely impacted. If you save an action, as far as
> opening a link or calling a helper app, there
> is absolutely no way to edit that pref. Apart from saving your
> mimeTypes.rdf (or a null version of same) you are
> stuck with your decision.
Sorry, I wasn't aware of this regression. It does sound like a problem.
I'll follow up in the bug.
-myk
JoeS
> JoeS wrote:
>> These things are constantly cropping up, some serious, some not.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=413200 has lingered now
>> for a week or so.
>>
> Well, a bug with so much activity in one week...I wouldn't call that
> "lingering" ;-) I guess your expectations are quite high...
>
I'll just call that "Firefox centric" development. If we are going to get more nightly testers involved, which I think is
really necessary for the advancement of 3.0 we deserve a little respect (as does tbird itself)
The trunk has been busted for periods of several weeks in the past due to core problems. Not a good incentive for testing.
David Ascher
well as encouraging volunteer contributors, hiring a build engineer,
promoting test suite development, etc.
Joe - don't hesitate to let me know of specific bugs which need
attention, and I'll see what I can do about raising their profile. I
know for a fact that Myk cares a lot about Thunderbird, and I'm sure
that he respects it plenty =).
--david
Pascal Sartoretti
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
> - a better search experience, especially for message content searches
> - a better overall user experience
I would add RSS to this list of features:
1. Thunderbird has a very basic RSS support, but it is barely usable due
to numerous usability issues (if there were only a few, I would have
created issues in Bugzilla).
2. Thunderbird already wraps together an e-mail client and an NNTP
client. Although some prefer to read RSS feeds in their browser, many
others (including me) think that reading RSS feeds is an activity which
closely resembles reading NNTP newsgroups.
3. The basic infrastructure for an excellent RSS reader is already
present in Thunderbird (HTML viewer, search folders, proxy options, etc...).
4. An excellent RSS reader would also increase the user base, which is a
goal of Thunderbird 3.
Hence, I think that with a reasonable effort Thunderbird could become a
great RSS reader.
Pascal
Arivald
My company almost decide to use Exchange. So if we want to have calendar
built-in, then maybe there should support for Exchange features.
Or at least it should be possible to make extension which provide needed
functionality.
--
Arivald
Simon Paquet
> * Goal: to have at public milestone build of Thunderbird 3 in 2008.
> Thunderbird 3's overall aim is to significantly grow its user base
> worldwide, as well as build a strong foundation for later
> Thunderbird releases.
>
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
> - a better search experience, especially for message content searches
> - a better overall user experience
These sound like fine goals to me.
> * Schedule: Figuring out the schedule at this stage is hard, as it
> will depend on who shows up with energy and talent. I would like
> to set some placeholder milestones for discussion, however:
>
> - alpha builds in Q1
> - beta builds without calendaring starting in Q2
> - beta builds with calendaring starting in Q3
While this sounds great in theory, it has some pretty drastic
implications for Calendar development, which one should be aware of.
| Note: I speak only for myself and from my own experience here. The
| only person who can speak with authority about the Calendar
| project is Daniel Boelzle, our lead developer.
Currently Calendar development happens exclusively on the 1.8 branch
to enable us to fully support TB2. All changes are cross-committed
to the trunk as well, but due to API and other architectural changes
there exist several pretty serious regressions on the trunk that we
know about.
There are probably even more regressions which we don't know about,
because we've told our testers to focus their testing on the 1.8 branch
and only a few are testing trunk builds once in a while.
I'm not a software engineer, but I would expect that it would take us
at least a month to play catchup on the trunk and fix the outstanding
regressions. This would of course mean that our planned feature
implementations for 0.9 and 1.0 would have to be postponed for said
month.
In addition it would increase the work for developers and reviewers,
who right now are not obliged to test their code on the trunk. It
would also mean that we need more manpower in the testing community,
but I'm not very concerned about that, since the inclusion into TB3
nightlies would probably result in a QA manpower increase.
> * The Mailnews/Thunderbird folks and the Calendar folks will have
> to figure out how to best allocate dev and testing effort on the
> calendaring features, how we support Sunbird, etc.
We'll have to think long and hard about what we'll do with Sunbird.
We'll also have to think whether we want to support SeaMonkey and how
much we want to support it, given that those guys will most likely
release alpha or beta releases of SM2 during that timeframe as well.
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Pascal Sartoretti
> I'm certainly interested in figuring out the various "enterprise" requirements.
Full Exchange support would be nice :-)
More seriously, I think that one single feature would greatly help the
use of Thunderbird in Exchange-based companies: the ability to *answer*
to meeting requests (currently, Thunderbird simply *displays* meeting
requests).
Pascal
Simon Paquet
This is already possible if you install the Lightning extension.
Pascal Sartoretti
>> More seriously, I think that one single feature would greatly help the
>> use of Thunderbird in Exchange-based companies: the ability to
>> *answer* to meeting requests (currently, Thunderbird simply *displays*
>> meeting requests).
>
> This is already possible if you install the Lightning extension.
Ooops, you're right, Lightning now supports it. However, the message it
sends back to the meeting requester is a simple text message, no a
(proprietary) Exchange acknowledgment. Hence, the meeting request in the
requester's calendar will not be updated, and the requester will notice
that I am a "second class citizen" in term of Exchange integration.
Anyway, Lightning is getting better, congratulations!
Pascal
Robert Kaiser
> 1. Thunderbird has a very basic RSS support, but it is barely usable due
> to numerous usability issues (if there were only a few, I would have
> created issues in Bugzilla).
You should still file bugs, no matter how many or how big the issues are.
Robert Kaiser
Robert Kaiser
> Currently Calendar development happens exclusively on the 1.8 branch
> to enable us to fully support TB2. All changes are cross-committed
> to the trunk as well, but due to API and other architectural changes
> there exist several pretty serious regressions on the trunk that we
> know about.
Maybe the time is arriving where that cross-commit policy needs to be
lifted (I know, that's also a question of manpower).
> We'll have to think long and hard about what we'll do with Sunbird.
True. Unfortunately the case is not as simple as with e.g. ChatZilla
here, which is able to run both as an extension and as a XULRunner app
with practically the same code - Lightning not being run in its own
window complicates things there.
> We'll also have to think whether we want to support SeaMonkey and how
> much we want to support it, given that those guys will most likely
> release alpha or beta releases of SM2 during that timeframe as well.
Yes, SeaMonkey surely will do Alphas and Betas, hopefully even a final
release of SeaMonkey 2 in that timeframe. We do not plan to ship with
Lightning in this cycle (yet), but it would be nice if we get it to run
in SeaMonkey, part of which can be achieved through making SeaMonkey
MailNews more similar to Thunderbird, but other parts might need some
patches in Lightning as well.
Robert Kaiser
Robert Kaiser
> * Less user-visible but important goals include:
The change from wallet to toolkit's LoginManager should be added here.
Mark Banner has done some work for that, see
https://bugzilla.mozilla.org/show_bug.cgi?id=239131 and its dependencies.
Robert Kaiser
SanderG
David,
Thanks for sharing the planning. Imho it's a good starting point for
discussion.
Personally I think the points you mention are very good. There are also
some other points I hear from users around me that would help user
adoption, such as:
- Corporate users:
1. Sync the calendar with Exchange, without needing Outlook. Use OWA or a
provider to sync with the Exchange calendar;
2. Ease the install and maintainability of the software. Installing
updates is a pain, and sometimes users manage to download an update and
are unable to apply it, after which it sticks in their profile until
someone pinches it out with a needle;
- Home users:
Integration with e.g. the Windows Address Book (read and write), Gmail
IMAP (including the Google recommended changes to the Thunderbird
settings for cache and attachment fetching, saving sent messages etc.)
What I would also appreciate is more external address book functionality
- store it on Mozilla servers (Weave?), LDAP server support including
ldap-write, Google account address book or something like that, so users
with multiple accounts can sync their address book and share it with
their family.
The most important one would be Exchange calendar sync. If that cannot be
done very soon it might still be worthwhile to _mention_ it so people
know that it's on the radar.
Regards
Sander
Simon Paquet
>> Currently Calendar development happens exclusively on the 1.8
>> branch to enable us to fully support TB2. All changes are
>> cross-committed to the trunk as well, but due to API and other
>> architectural changes there exist several pretty serious
>> regressions on the trunk that we know about.
>
> Maybe the time is arriving where that cross-commit policy needs
> to be lifted (I know, that's also a question of manpower).
I don't understand this. What do you mean with lift the cross-commit
policy of mozilla/calendar?
We can't just switch to the trunk. We have a few hundred thousand users
on TB2 and we can't just let them hang out in the open while TB3 is
still in alpha, beta or RC stage.
So at least until Lightning 1.0 is released (probably even longer) we
will stay on the branch or at least commit a major part of our
development resources there.
Pascal Sartoretti
> You should still file bugs, no matter how many or how big the issues are.
Here is what I think about RSS support in Thunderbird: the whole
configuration UI is a mess, I am confused between what is a feed, a
subscription, a location and a folder (from a user point of view, they
are pretty much all the same...).
I don't know how to express this in a constructive way in Bugzilla :-)
On the other hand, the UI for reading RSS is ok.
Just a question to Thunderbird users: who also uses it for RSS?
Pascal
Simon Paquet
> Thanks for sharing the planning. Imho it's a good starting point for
> discussion.
>
> Personally I think the points you mention are very good. There are
> also some other points I hear from users around me that would help
> user adoption, such as:
>
> - Corporate users:
>
> 1. Sync the calendar with Exchange, without needing Outlook. Use OWA
> or a provider to sync with the Exchange calendar;
Exchange support would be great to have of course, but it is
absolutely impossible to achieve this in the TB3 timeframe that David
proposed.
In addition the only viable open source solution that could be used
to quickly add Exchange support to Thunderbird and Lightning (libmapi)
can not be used because of license imcompatibilities (libmapi uses
GPLv3, while we use the MPL/LGPL/GPL tri-license).
Unless the libmapi developers change their license, we would have to
implement this stuff from scratch, which would probably take at least
1-2 years to reach a "basic support"-milestone.
Peter Lairo
> David Ascher wrote:
>> * Release-defining features:
>
I disagree that RSS is important to Thunderbird. Reading RSS in a
three-pane e-mail program is painful because the articles are set up
like web pages (i.e. vertically long) and having to read them in *half
the vertical space* of the Thunderbird window (the message pane)
severely limits the needed vertical space. Also, RSS feeds are basically
*web pages* and thus have more to do with a browser than an e-mail program.
I would much rather see Thunderbird's very limited resources be used on
(IMO more important) things like:
Improving the chi-square spam detection method
https://bugzilla.mozilla.org/show_bug.cgi?id=243430
Ignore (kill) a Subthread (branch: not the whole thread)
https://bugzilla.mozilla.org/show_bug.cgi?id=11054
Define official Mozilla LDAP schema extension
https://bugzilla.mozilla.org/show_bug.cgi?id=116692
XP way to show number in current locale (with correct decimal and
thousands separators) needed
https://bugzilla.mozilla.org/show_bug.cgi?id=108689
Add birthday fields to address book
https://bugzilla.mozilla.org/show_bug.cgi?id=13595
ship with a pre-populated training.dat file?
https://bugzilla.mozilla.org/show_bug.cgi?id=179999
Hide/Mute quoted text
https://bugzilla.mozilla.org/show_bug.cgi?id=35929
Use a SQLite Database for Storing Mails
https://bugzilla.mozilla.org/show_bug.cgi?id=361807
requesting conversion from mork db to sqlite for addressbooks
https://bugzilla.mozilla.org/show_bug.cgi?id=382876
<blockquote type="cite"> is nonstandard
https://bugzilla.mozilla.org/show_bug.cgi?id=183219
[Tracking] Critical roaming bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=228629
Roaming for Thunderbird (synchronize, synchronization)
https://bugzilla.mozilla.org/show_bug.cgi?id=310158
Dragging email over closed folder doesn't open (expand) sub folders
https://bugzilla.mozilla.org/show_bug.cgi?id=338401
Ability to select from multiple signatures (global / per account?)
https://bugzilla.mozilla.org/show_bug.cgi?id=73567
put signature editing in UI (rather than select a file)
https://bugzilla.mozilla.org/show_bug.cgi?id=324495
Would like to see a space between number and "kB" in message size
https://bugzilla.mozilla.org/show_bug.cgi?id=302143
Need: View -> Messages -> Watched Thread (ALL, not just "Unread")
https://bugzilla.mozilla.org/show_bug.cgi?id=294901
Turn off Extra Send Progress Window by Default
https://bugzilla.mozilla.org/show_bug.cgi?id=218557
RFE: "Compact" or "Purge" button
https://bugzilla.mozilla.org/show_bug.cgi?id=75927
Many of these bugs already have code that needs to be checked-in or are
trivial to fix. Others are very difficult but also very important.
BTW: I would also prefer if Firefox improved its nearly unusable RSS
feeder - ideally by integrating the lean and only truly usable *Sage*
Add-on.
https://addons.mozilla.org/en-US/firefox/addon/77?id=77
--
Regards,
Peter Lairo
The browser you can trust: http://www.GetFirefox.com
Reclaim Your Inbox: http://www.GetThunderbird.com
Pascal Sartoretti
> I disagree that RSS is important to Thunderbird. Reading RSS in a
> three-pane e-mail program is painful
A matter of taste (and monitor size).
RSS support should either be improved or suppressed.
Mark Banner
> I'm not a software engineer, but I would expect that it would take us
> at least a month to play catchup on the trunk and fix the outstanding
> regressions. This would of course mean that our planned feature
> implementations for 0.9 and 1.0 would have to be postponed for said
> month.
I understand the impact on the future releases, but what is your current
timescale for them (I couldn't see after a quick look on the calendar wiki)?
What I'm thinking, is that how close are 1.0 and TB3 likely to be? Do
you really want to be releasing a 1.0 that doesn't work with TB3 which
is going to be out just around the corner?
Not only that, if they are close enough why not just release them at the
same time?
I can understand the reluctance, but I can also see some advantages to
bringing lightning up to spec on trunk.
Standard8
ovidiu
I kinda use it for reading RSS. Though, I should probably say I use
it, not necessarily for reading as for the backup,offline, markup it
allows. But this goes only for couple of news and blogs that are very
important or that I contribute. Not very usefull, though, as changes in
those posts or other things are not there. But finally, I have to say
that I probably just play with it cause is there and was curious and is
in the same place/sistem as the mail. Could live without..
I would really use it (more) if for there would be tools to allow a
more convenient following or contributing. This means that I can usually
have those RSS as mails too, and not much of a difference. While, if I
could see them along with comments (threaded) and being able to comment,
post, edit etc those, it would be a real tool [as for the UI, that's
another story..]. Till then, there should simply be more media readable
here to make it work (vlogs, posts embeding vids etc..)
On the other hand, my impression is that standards and procedures
concerning this area are not so stable and final and thus, the web may
be a simple answer. I cannot tell how important is this among
features/areas for TB. While a blogging tool (as I describe in the
second..) is already a completly different thing.
Norbert Püschel
> It's time to define the Thunderbird 3 plan. I've spent a fair bit of
> time learning about the state of affairs and talking to many people, and
> I feel I've accumulated enough information to start this process.
>
>
> * Goal: to have at public milestone build of Thunderbird 3 in 2008.
> Thunderbird 3's overall aim is to significantly grow its user base
> worldwide, as well as build a strong foundation for later Thunderbird
> releases.
>
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
In other words, wouldn't that effectively terminate Lightning as an
independant project? I don't like this. Lightning is IMHO not developed
enough to be chained to Thunderbird in it's release cycle. But better
someone of the Lightning development team say something about this.
> - a better search experience, especially for message content searches
> - a better overall user experience
>
> * Less user-visible but important goals include:
> - Significant headway on getting rid of Mork and RDF
What is more important than killing Mork is IMHO making the address book
extensible and adding a useful synchronisation interface to it. I'm sick
of programs like iTunes that only sync to Outlook. Writing addressbook
synchronisation is quite complicated with Thunderbird 2...
Norbert Püschel
ovidiu
move towards a more 'organizing' thing including those rss, could be
another case. A previous discussion here, regarding AB as fundament for
communication and pim, may show TB as support (eventually) for a more
complex relationship between different tipes of data/links where rss
would fit among some data. Another direction could be to serve those
that contribute to rss and other directions may arrise. Aniway,
improving rss is one thing, while others may be a priority.
Chris Ilias
> * Release-defining features:
> - an integrated calendaring feature, based on Lightning
> - a better overall user experience
>
> * Less user-visible but important goals include:
> - Significant headway on getting rid of Mork and RDF
> Thunderbird, including refactorings, FUEL, developer documentation, and
> user experience
> - Better test coverage and performance metrics in place to support
> refactoring goals
>
> There will be of course lots of other bug fixes and enhancements
> (patches welcome ;-))
Is it too late to recommend items for the PRD?
Things I think would make Thunderbird rock:
_Account setup library_
Personally, I'd like to see an extensive library of account setup files.
<http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>
No Thunderbird user should ever have to type in the server name, port
number, when setting up an account.
_Add-ons browser_
One of Firefox's biggest advantages over the competition is the add-ons
functionality. Thunderbird has it as well, and there are plenty of
extensions to satisfy people's complaints about Thunderbird; but
finding/installing add-ons for Thunderbird is much less user-friendly.
Users should have to "Save link as" from AMO, then use Thunderbird to
open the file. Many users either mistakingly install Thunderbird add-ons
in Firefox, or double-click on the XPI after having downloaded it. The
add-ons browsing experience should take place within Thunderbird. You
can even use this to browse account setup files.
Some other frequent items in the support newsgroup:
- profile backup/restore feature
- webmail support (Hotmail, Yahoo!, etc.)
- newsgroup binary combine and decode
- account re-ordering
> * Schedule: Figuring out the schedule at this stage is hard, as it will
> depend on who shows up with energy and talent. I would like to set some
> placeholder milestones for discussion, however:
>
> - alpha builds in Q1
> - beta builds without calendaring starting in Q2
> - beta builds with calendaring starting in Q3
> - widely useful builds by Q4 (although whether they're branded "release"
> will depend on quality, as always).
>
> We're revise the schedule as we gain knowledge.
I hope the eagerness to get something out the door within the year won't
hurt the quality of the release. (e.g. Netscape 6)
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
Simon Paquet
>> I'm not a software engineer, but I would expect that it would take
>> us at least a month to play catchup on the trunk and fix the
>> outstanding regressions. This would of course mean that our planned
>> feature implementations for 0.9 and 1.0 would have to be postponed
>> for said month.
>
> I understand the impact on the future releases, but what is your
> current timescale for them (I couldn't see after a quick look on
> the calendar wiki)?
Our current plan (AFAIK, I'm not the one making the decisions) was
that we would release 1.0 somewhere in October or November 2008 and
move to the trunk afterwards.
> What I'm thinking, is that how close are 1.0 and TB3 likely to be?
> Do you really want to be releasing a 1.0 that doesn't work with TB3
> which is going to be out just around the corner?
I was not saying that we did not want to release a 1.0 that does not
work with TB3. I was just saying that making that possible has
consequences with regards to when we can push out our next releases.
If it was just about aligning our releases with Thunderbird, I'm sure
we could accomodate, but we'll also have to look at what Sun wants to
do with OpenOffice 3.0 (Sun funds roughly 60% of our devs) and whether
they want OO 3.0 with Thunderbird plus Lightning (see
http://slashdot.org/article.pl?sid=07/10/14/1248233).
> Not only that, if they are close enough why not just release them
> at the same time?
>
> I can understand the reluctance, but I can also see some advantages
> to bringing lightning up to spec on trunk.
We are not reluctant per se, it just means more work for developers
and testers to work in parallel on branch and trunk. And more work
means less fixes in a given timeframe, which results in a longer
preparation time for a release if we assume a fixed developer headcount.
Mark Banner
> What is more important than killing Mork is IMHO making the address book
> extensible and adding a useful synchronisation interface to it. I'm sick
> of programs like iTunes that only sync to Outlook. Writing addressbook
> synchronisation is quite complicated with Thunderbird 2...
Although it hasn't branched out here yet, we are looking at making the
address book more extensible and improving its API at the same time as
looking at killing Mork.
Admittedly synchronisation is still one thing I need to look at on the
API front, but we are thinking about it.
Standard8
Mark Banner
> _Account setup library_
> Personally, I'd like to see an extensive library of account setup files.
> <http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>
> No Thunderbird user should ever have to type in the server name, port
> number, when setting up an account.
I disagree with that. Unless you want to provide a constantly updated
list of all the ISPs available to users across the world.
I would much rather we start encouraging ISPs to provide "easy"
configuration extensions that users can just download and install as needed.
Standard8
Simon Paquet
>> * Release-defining features:
>> - an integrated calendaring feature, based on Lightning
>
> In other words, wouldn't that effectively terminate Lightning as
> an independent project? I don't like this. Lightning is IMHO not
> developed enough to be chained to Thunderbird in it's release
> cycle. But better someone of the Lightning development team say
> something about this.
There are a few answers to this:
- Yes, in its current state Lightning is not ready for TB inclusion.
We hope to have it ready when we reach 1.0
- The release cycles of Lightning and TB differ significantly at the
moment. TB will probably only push out one major release every
12-18 months, while Lightning is currently being updated every
4 months
- We could still release updates of Lightning if Lightning would still
be treated as an extension internally and major TB releases could
contain an update.rdf file pointing to addons.mozilla.org where we
would release updates to Lightning
ovidiu
> It's time to define the Thunderbird 3 plan. I've spent a fair bit of
> time learning about the state of affairs and talking to many people,
> and I feel I've accumulated enough information to start this process.
>
> newsgroups, but expect discussion on the thunderbird newsgroup and
> have set followup-to accordingly. There will be a summary post in the
> planning newsgroup if the final plan differs significantly from the
> one outlined here.
>
> The long-term roadmap of Thunderbird is still in flux, but there are
> four high-level points which drive my thinking about Thunderbird 3:
>
> 1. Thunderbird's impact is proportional to its user count. Thus
> driving adoption is my primary concern. Our current user base is very
> significant (many millions of mostly quite satisfied users), but the
> number of possible users of Thunderbird is orders of magnitude greater
> than our current reach.
>
> 2. The reasons why people don't choose to use Thunderbird are varied,
> but two primary reasons appear to be: the lack of a built-in calendar
> integration (compared to Outlook for example), or a search experience
> that doesn't match that offered by competitors (gmail and Mail.app for
> example).
>
> 3. In addition, Thunderbird's codebase has a fair bit of technical
> debt due to insufficient resourcing over the years, which has led to a
> codebase which has too many scary bits, not enough test coverage, and
> isn't yet able to leverage the ongoing platform improvements. In
> addition, while communications clients are by nature great targets for
> extension authors, the current codebase isn't extension-friendly
> enough, making it too hard to build installation-specific features or
> experiment with new feature ideas.
>
> 4. A fair number of Thunderbird changes have already landed on trunk,
> including some important bug fixes, by a variety of contributors.
> There's appropriate pressure to ship an update to Thunderbird 2 to
> take advantage of those and of the platform improvements.
>
> With all that as background, I propose:
>
> * Goal: to have at public milestone build of Thunderbird 3 in 2008.
> Thunderbird 3's overall aim is to significantly grow its user base
> worldwide, as well as build a strong foundation for later Thunderbird
> releases.
>
> - an integrated calendaring feature, based on Lightning
> - a better overall user experience
>
> * Less user-visible but important goals include:
> - Significant headway on getting rid of Mork and RDF
> - A concerted effort to improving the extensions ecosystem for
> Thunderbird, including refactorings, FUEL, developer documentation,
> and user experience
> - Better test coverage and performance metrics in place to support
> refactoring goals
>
> There will be of course lots of other bug fixes and enhancements
> (patches welcome ;-))
>
> will depend on who shows up with energy and talent. I would like to
> set some placeholder milestones for discussion, however:
>
> - alpha builds in Q1
> - beta builds without calendaring starting in Q2
> - beta builds with calendaring starting in Q3
> - widely useful builds by Q4 (although whether they're branded
> "release" will depend on quality, as always).
>
> We're revise the schedule as we gain knowledge.
>
> be figured out closer to the endgame (and reviewed next when 1.9 is cut),
>
> * The Mailnews/Thunderbird folks and the Calendar folks will have to
> figure out how to best allocate dev and testing effort on the
> calendaring features, how we support Sunbird, etc.
>
> of new feature develoment, integration and stabilization work
> involved, help of all kinds is more than welcome! Thanks in advance
> for any input you may have, either on process or on deliverables.
>
> The central wiki page for Thunderbird 3 is
> http://wiki.mozilla.org/Thunderbird:Thunderbird3. IRC discussion will
> take place in #maildev. The newsgroup/mailing list of record for Tb3
> is mozilla.dev.apps.thunderbird.
>
> I look forward to the discussion!
>
> -- David Ascher
What about the documentation,(+ help, support and tutorial, along with
'built in usability helpers' (I'll detail that)) for the next release or
generally in TB area?
I do emphasize on the documentation and help cause I strongly think that
if more users to come, the harder it will be to manage that, and a
disappointment (motivated or not) regarding the usage/miss usage of the
app may lead to undesired effects (break enthusiasm..). Obviously, I
consider the documentation, help and generally information for the user,
subject to a growing entropic phenomenon (read a spreading mess) witch
at least needs consolidation and updating, if not a rethink. This is
very much related to the perception of the app in terms of safety and
even maturity from the standard user.
[ I understand that it can be a separate or parallel process, the
rethinking of the user doc and help. But it is somehow a parallel one
also in terms of HR and tasks, enough to be less of a problem to the
people/processes listed above. I mean, should not necessarily put more
stress directly on the aggressive schedule.
Also it may fall under the 'a better overall user experience', but
is somehow a very important thing to consider in terms of the first 'get
more users' idea. Also there may be some things worth being built in, or
things to consider as helpers along the way, like those today that are
from 'alt text' to 'wizards' and somewhere in between the very things
that visually indicate what they do. For such 'built in and usability
helpers' may be the essence of designing the product..]
Anyway, the question is, again, where is the place of 'user
documentation works' (to make it short)?
Gary Kwong
>
> I was not saying that we did not want to release a 1.0 that does not
> work with TB3. I was just saying that making that possible has
> consequences with regards to when we can push out our next releases.
>
> If it was just about aligning our releases with Thunderbird, I'm sure
> we could accomodate, but we'll also have to look at what Sun wants to
> do with OpenOffice 3.0 (Sun funds roughly 60% of our devs) and whether
> they want OO 3.0 with Thunderbird plus Lightning (see
> http://slashdot.org/article.pl?sid=07/10/14/1248233).
There should soon be discussions between the Thunderbird dev team
(MailCo) and Calendar dev team to discuss this.
Given time, I'm sure something can be worked out.
Gary
Daniel Boelzle
I am quite excited about David's plans incorporating a calendar facility
into Thunderbird 3; it's a great opportunity to actually get a growing
user base!
Wearing my calendar glasses, there are of course quite a couple of
topics that need attention and some have already been mentioned, like
* branch vs. trunk, when is the right time to move over?
=> I don't think we could reliably manage both branches, and I'd opt
for a reasonable move to trunk/1.9 once the TB3 codeline has settled. I
think it's too early to nail that down to a specific calendar release
0.9 or 1.0.
* deployment: will lightning still come as a (preinstalled) extension?
=> IMO this heavily depends on how calendar will evolve in the future
(feature like) and how mature it'll be (w.r.t. quality). My *current*
view on things is that I'd vote to keep it as an extension, being able
to deliver new features and necessary bugfixes frequently.
* What about Sunbird?
=> I expect little changes: we should head for feature parity if
possible, but we have to face that focus will likely move even more to
lightning, because of it's growing user base.
regards,
Daniel
> _______________________________________________
> dev-apps-calendar mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-calendar
Daniel Boelzle
> In addition the only viable open source solution that could be used
> to quickly add Exchange support to Thunderbird and Lightning (libmapi)
> can not be used because of license imcompatibilities (libmapi uses
> GPLv3, while we use the MPL/LGPL/GPL tri-license).
>
> Unless the libmapi developers change their license, we would have to
> implement this stuff from scratch, which would probably take at least
> 1-2 years to reach a "basic support"-milestone.
samba libs. While that works for *nix, it's not trivial for Windows.
Incorporating 3rd party libraries are always a pain, so this needs to be
carefully considered. We could always opt for an extension based
solution, of course (instead of adding such code to cvs.mozilla.org).
regards,
Daniel
David Ascher
> What about the documentation,(+ help, support and tutorial, along with
> 'built in usability helpers' (I'll detail that)) for the next release or
> generally in TB area?
>
Absolutely, documentation, for users, for extension authors, and for
developers, is an area needing attention -- luckily, apart for API
specific information and things like FUEL, much of it can happen
independently of the release process.
> Anyway, the question is, again, where is the place of 'user
> documentation works' (to make it short)?
>
I'm still gathering information about what the state of user
documentation is, where the best resources are, how to best coordinate
with the work of the Mozillazine community (and equivalents throughout
the world), SUMO, etc. I would appreciate it if someone could put
together a summary of the state of user docs for Tb on a wiki page
somewhere, that'd save me considerable time.
--david
David Ascher
> Wearing my calendar glasses, there are of course quite a couple of
> topics that need attention and some have already been mentioned, like
> * branch vs. trunk, when is the right time to move over?
> => I don't think we could reliably manage both branches, and I'd opt
> for a reasonable move to trunk/1.9 once the TB3 codeline has settled. I
> think it's too early to nail that down to a specific calendar release
> 0.9 or 1.0.
> * deployment: will lightning still come as a (preinstalled) extension?
> => IMO this heavily depends on how calendar will evolve in the future
> (feature like) and how mature it'll be (w.r.t. quality). My *current*
> view on things is that I'd vote to keep it as an extension, being able
> to deliver new features and necessary bugfixes frequently.
> * What about Sunbird?
> => I expect little changes: we should head for feature parity if
> possible, but we have to face that focus will likely move even more to
> lightning, because of it's growing user base.
>
Agree with all the above. We need to somehow balance the needs of
Sunbird users, Thunderbird 2 + Lightning users; Thunderbird 3 users;
Seamonkey users; developers (both calendar-focused and mailnews
focused); testers of all of the above; localizers of all of the above;
documentation authors for all of the above; and likely more I'm forgetting.
I'm intrigued by the idea of keeping Lightning as a bundled preinstalled
extension. It could allow for interesting upgrade paths down the line,
and I'd guess anything else would make it quite tricky to manage both
1.8 and trunk work. It may be the right incremental step, at least
until there are compelling arguments to do a "deeper" integration, which
I suspect won't come out until we have a clearer picture of the
differences between the Tb3 UX and the Tb2+Lightning UX.
--david
David Ascher
>
> Although Chris didn't specify, I believe he means exactly that, the ISP
> provides the extension already configured. Easy enough to do being an
> ISP myself. An RDF file with a million ISP listings is a bit out of the
> realm of reason. ;-)
>
However, I do like the idea outlined in
http://wiki.mozilla.org/Thunderbird:Easy_Account_Setup#Hosted_Web_Service
--david
Mark Banner
> I'm intrigued by the idea of keeping Lightning as a bundled preinstalled
> extension. It could allow for interesting upgrade paths down the line,
> and I'd guess anything else would make it quite tricky to manage both
> 1.8 and trunk work. It may be the right incremental step, at least until
> there are compelling arguments to do a "deeper" integration, which I
> suspect won't come out until we have a clearer picture of the
> differences between the Tb3 UX and the Tb2+Lightning UX.
Just picking up on this, now that SeaMonkey has the new add-on manager,
it will still be shipping some extensions (Inspector, Chatzilla,
JavaScript Debugger - aka venkman) pre-installed as extensions.
For the installer builds there will be an option to disable the
installation of the various extensions.
Some of this has already been tested. Its worth noting that updates to
extensions will be installed in the user's profile (due to admin
privileges etc), whereas the pre-installed extensions will be global.
There's possibly some bugs there, but we believe the general idea is
do-able.
Standard8
mozil...@zindus.com
> What is more important than killing Mork is IMHO making the address book
> extensible and adding a useful synchronisation interface to it.
Some ideas around better support for sync in the addressbook:
- change detection
- stable identifiers for content
- distinguishing content and meta-data updates
- rationalising mailing lists
And independent of whether the AB uses Mork, it would be good to have a
decent datastore for sync-related meta-data (sqllite?).
Leni.
David Ascher
that just posting them here is likely to get them lost. If you'd like
to have features considered for Tb3, I suggest that the usual process be
followed:
1) file enhancement requests (or find existing ones) in bugzilla
2) Until we figure out a flag policy for tb3, add a pointer to each bug to:
http://wiki.mozilla.org/Thunderbird:Thunderbird_3_Possible_Bugs
or
http://wiki.mozilla.org/Thunderbird:Thunderbird_3_Possible_Enhancements
depending on whether they're bugs w/ existing functionality or enhancements.
More broad points (like the point about documentation and data
migration), which don't fit so neatly in bugs but are more
consciousness-raising arguments, make more sense on the discussion forum
IMO.
--david
ovidiu
delivered as preinstalled and this should show up in the:
-install process, as options (full-tb+lt+../min-mail only /custom...)
-add-on manager, telling people that those are segments of functionality
etc, not to accidentally uninstall
-maybe persistent in the addon manager, so that even if one
del/uninstall LT or choses not to install first but maybe later, it will
still show there grayed, giving an option for install at any point. this
may apply to others as necessary, achieving the effect of a modular soft
and giving more confidence in those extensions.
This kind of modular app actually based on extensions may lead to even
other ideas.
Kent James
> I'm intrigued by the idea of keeping Lightning as a bundled preinstalled
> extension.
>
>
Have you considered expanding this concept to additional functionality?
For example, in the area of spam management, there is a pretty large
difference in how much information people want. Some people want a
fairly silent spam management solution, others would like to more
actively manage things. Rather than bloating the main application with a
bunch of options, it might be better to package with TB something like
an expanded spam management package. This would include things like
three-state visibility of status, display of bayes scores, UI to change
the bayes score cutoff point, and visibility of the tokens used to
determine status. A spam management extension might also include some
ability to update spam handling more frequently than the main
application changes, to better respond to clever tactics by spammers.
This is an example, not a proposal, at least within this thread. The
proposal is that bundled pre-installed extensions be an accepted way to
manage functionality bloat or preferences in the TB releases. Although
such things could also be done in unbundled extensions, I really think
the core product would benefit from more extensions that are maintained
by the central organization, and kept up to date and localized with the
same commitment as the main product.
rkent
David Ascher
> David Ascher wrote:
>
>> I'm intrigued by the idea of keeping Lightning as a bundled preinstalled
>> extension.
>>
>> --david
>>
>>
> Have you considered expanding this concept to additional functionality?
>
every combination of choices needs testing and each component needs to
be coordinated with every other one. Lightning is fairly unique among
extensions in that it already has a strong developer community, testing
practices, frequent public releases, a roadmap, etc. and even with that
I expect it'll be hard enough to coordinate the two efforts!
As to the integration of functionality that's currently in extensions
(whether as pre-bundled extensions or as regular patches), I am always
eager to hear about under-appreciated extensions. I routinely find out
about useful add-ons from casual conversations, and I certainly would
want to talk to the authors of these add-ons to explore the
possibilities of integrating some of their ideas or code into the project.
--david
ovidiu
> ovidiu wrote:
>> What about the documentation,(+ help, support and tutorial, along
>> with 'built in usability helpers' (I'll detail that)) for the next
>> release or generally in TB area?
>>
>
> Absolutely, documentation, for users, for extension authors, and for
> developers, is an area needing attention -- luckily, apart for API
> specific information and things like FUEL, much of it can happen
> independently of the release process.
independence. And I do consider as separated user and dev cause the
goals of those docs are somewhat distinct and subject to different areas
even in this plan. User doc being of importance for all usage, while dev
is another thing.. [Not sure if I'm right, though. In this regard, where
would visual customization (css?) go?]
>> Anyway, the question is, again, where is the place of 'user
>> documentation works' (to make it short)?
>>
> I'm still gathering information about what the state of user
> documentation is, where the best resources are, how to best coordinate
> with the work of the Mozillazine community (and equivalents throughout
> the world), SUMO, etc. I would appreciate it if someone could put
> together a summary of the state of user docs for Tb on a wiki page
> somewhere, that'd save me considerable time.
>
> --david
>
where with some comments, could help on that ( well, partially, as I
wouldn't go into dev). If regards some undergoing doc already taking
place, hm..
If first, indicate a place as appropriate. I don't dear to say I'll do
it, but can start..
ovidiu
Clint Talbert
..snip..
David, overall I think this looks like a great plan.
I'd like to follow on with my list of issues that need to be figured
out/handled for a TB 3.
= Thunderbird Pieces =
* Address Book improvements - these are noted elsewhere, but removing
Mork, RDF and being able to use other addressbooks is a very critical
piece of the puzzle.
(Some of the following might already be fixed on trunk - I use and test
on branch, since I work on Lightning)
* Signature verifying. I have an email server that is xxx.foo.org but
its signature is xxx.bah.org I know this is ok, that the foo.org is just
a different virtual domain on that host. But Thunderbird has to tell me
several times a day about this. I'd love to be able to click "OK,
remember this" and be done with it.
* IMAP timeouts/network robustness. I've heard that this is in fact
fixed on trunk, but have not been able to verify that. Everytime I
switch networks, come back from sleep, Thunderbird goes out to pasture
and spins for quite a while.
* Add-Ons - we need an add on strategy for thunderbird. Having the user
right click, save as, and then Install the add-on from disk is a
completely broken process.
* Making it easier for people to enter their ISP information. This was
mentioned elsewhere. I think this is a great idea that we should take,
and I think it could be incorporated into the "L10N" process in order to
have a viable alternatives for people all over the world.
* Searching: This is critical. As storage space gets cheaper, I find
myself never sorting anything anymore. I just search my inbox for it.
* Tagging: I've been using the tag feature,and it works really well.
I'd like to see it advanced. Make into something as intuitive and easy
and useful as the "Awesome Bar" has become in FFx 3.
* Creating an extension for Thunderbird is HARD. Developing and
learning the Thunderbird codebase is REALLY HARD. We need to lower
these hurdles as fast as we can. The Lightning UI team can probably
provide quite a bit of feedback on what would have made our experience
easier. One thing that would make all extension developers really
happy: An API to get extension foo's UI into the folder pane on the left
side of Tbird. Every extension developer for Tbird that I have ever
known (including myself) has always attempted to do this first.
Everyone I have talked to bailed out after several weeks/months of work.
* Better Mime Handling - Tbird 2 tends to download attachments several
times, depending on what you do. I think this might be fixed on trunk.
* Need to be able to configure mime handling in tbird we might be able
to reuse the functionality that Myk and Dmose have developed for FFx 3
in this.
* Performance - I also hear this is improved on trunk but it continues
to be my experience that I wait for thunderbird to download messages,
send messages and what have you. It's got to get faster.
* Testing - We need test servers. You can't expect volunteer QA folk to
be willing to sacrifice their personal email accounts for testing.
Likewise, we also need to find a way to create an automated test system.
For example, it should be easy to run an automated POP and IMAP and
(maybe) NNTP automated test under the covers.
* There are hundreds of Thunderbird Litmus testcases(litmus.mozilla.org)
we need to figure out who will own and update these so that the MailCo
team can begin using them for testdays in order to get a good
measurement of exactly where the trunk stands in terms of quality.
= Calendar Integration =
* Mime Handling - The way that I have to detect "does this email have a
text/calendar attachment" is completely silly. I have to get a callback
from the Mime parser, then I have to fire an event to an observer, who
has to depend that all of this is happening in the same thread and the
observer sets up the text/calendar information so that when the "message
load" event occurs, it knows that this is the message that belongs to
the "text/calendar" attachment. Obviously, this is fragile.
Bienvenu and I were able to make some changes for Tbird 2 to help this
matter - we store the message ID and can compare that.
But I'd love some easier way to determine what type of attachment we
have, so that we can load it easier and have a slightly more
deterministic mechanism for doing iMIP/iTIP
Perhaps what I'm asking for here is more ability (an API) for an
extension's code to plugin and access the message load/message parse
process.
* If you have "display attachments inline" unchecked, none of the above
happens and you don't get any notification of calendar meeting requests.
The text/calendar mime type should be whitelisted and exempted from
that feature. Or perhaps better, any mime type with an explicit
registered handler should be white listed from having to follow that
preference.
* iMIP security - we have a set of security restrictions that are
evolving as iMIP and iTIP RFC's are finalized. Currently, we have very
few mechanisms to vet those security restrictions because of the
disassociation between the mime/encryption handling and the UI. I
hesitate to make any explicit recommendations in this area since the
specs are still developing. iMIP is RFC 2447, for reference:
http://www.isi.edu/in-notes/rfc2447.txt
* More options on crafting emails. There are only a handful of
interfaces to use to send an email from within Thunderbird. It's
difficult to understand and control how that email is sent, what type of
Mime wrapper it uses, how the attachment is attached etc.
== Outlook Integration ==
* We invite anyone who wants to tackle the beast of integrating
Outlook/Exchange calendaring with Lightning to implement a Calendar
Provider for it:
http://mxr.mozilla.org/mozilla1.8/source/calendar/base/public/calICalendarProvider.idl
Speaking for the calendar team, I can say we'll help you as much as we can.
* Any time you talk about Outlook/Exchange, you also need to think about
syncing the Addressbooks as well. So, you'd also need to consider that.
And that would mean mapping somehow the insane number of contact
specific data available in those systems into a the Tbird UI.
This is my long rambling two cents. I apologize for anything I stated
that is already fixed on trunk and was already mentioned above.
Clint
David Ascher
>> I'm still gathering information about what the state of user
>> documentation is, where the best resources are, how to best coordinate
>> with the work of the Mozillazine community (and equivalents throughout
>> the world), SUMO, etc. I would appreciate it if someone could put
>> together a summary of the state of user docs for Tb on a wiki page
>> somewhere, that'd save me considerable time.
>>
>> --david
>>
>>
> Not sure I see exactly what this means. If an inventory of what and
> where with some comments, could help on that ( well, partially, as I
> wouldn't go into dev). If regards some undergoing doc already taking
> place, hm..
> If first, indicate a place as appropriate. I don't dear to say I'll do
> it, but can start..
>
Yup, that's what I meant.
To clarify: I don't have a good mental picture of what's good, bad, and
ugly about user docs, what work is planned, who'se doing what, etc. If
anyone has knowledgeable opinions about the above, writing them up and
putting together a proposal for what we could/should do for Tb3
regarding user docs would be very helpful.
As to a place to start, I've just created
http://wiki.mozilla.org/Thunderbird:Thunderbird3:UserDocs, feel free to
add to it.
--david
Bed
> I would add RSS to this list of features:
>
> 1. Thunderbird has a very basic RSS support, but it is barely usable due
> to numerous usability issues (if there were only a few, I would have
> created issues in Bugzilla).
>
> 2. Thunderbird already wraps together an e-mail client and an NNTP
> client. Although some prefer to read RSS feeds in their browser, many
> others (including me) think that reading RSS feeds is an activity which
> closely resembles reading NNTP newsgroups.
>
> 3. The basic infrastructure for an excellent RSS reader is already
> present in Thunderbird (HTML viewer, search folders, proxy options,
> etc...).
>
> 4. An excellent RSS reader would also increase the user base, which is a
> goal of Thunderbird 3.
>
> Hence, I think that with a reasonable effort Thunderbird could become a
> great RSS reader.
>
> Pascal
Hear Hear!
I couldn't agree with all of the above any more than I do.
Eddy Nigg (StartCom Ltd.)
> * Signature verifying. I have an email server that is xxx.foo.org but
> its signature is xxx.bah.org I know this is ok, that the foo.org is just
> a different virtual domain on that host. But Thunderbird has to tell me
> several times a day about this. I'd love to be able to click "OK,
> remember this" and be done with it.
>
is an NSS issue and does the right thing IMO. Why is your client
configured to access a "wrong" domain name? Shouldn't you have each
account configured accordingly, including SMTP of course?
Not sure why and when it asks you to confirm it, since you say "several
times a day". Does this happen randomly? Or after a certain time? It
doesn't make much sense right now, since either it warns you every time,
or only once, or perhaps if you are using IMAP then every time the
connection was dropped and established again. Which would match actually
your next issue below...
> * IMAP timeouts/network robustness. I've heard that this is in fact
> fixed on trunk, but have not been able to verify that. Everytime I
> switch networks, come back from sleep, Thunderbird goes out to pasture
> and spins for quite a while.
>
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Wayne Mery
> David Ascher wrote:
> ..snip..
> David, overall I think this looks like a great plan.
agree,
recognizing that david's first post to this thread was "big picture" and
can't possibly cover all bases, I'll echo some of clint's refinements ...
> * IMAP timeouts/network robustness. I've heard that this is in fact
> fixed on trunk, but have not been able to verify that. Everytime I
> switch networks, come back from sleep, Thunderbird goes out to pasture
> and spins for quite a while.
This area of robustness (not just spins of course) needs a good, hard
look, because the number of bugs and problems reported will increase in
direct proportion to the number of hoped for new users. Perhaps not a
big deal in the grand scheme of things like big new features and
infrastructure, but these problems compared to others I would argue are:
1. harder for users to describe, and often hard to reproduce
2. hard get correct data for developers
3. hard for developers to debug
4. too often easier for user to live with or ignore than report,
5. in some cases thought to be a network problem and therefore not
recognized and reported as a client problem
... and therefore deserving of special attention. But, it will require
appropriate attention by volunteers, arguably more volunteers, in
conjunction with David's team, plus a couple of the items below.
I'll add a big second to these two items both for me and my organization.
> * Searching: This is critical. As storage space gets cheaper, I find
> myself never sorting anything anymore. I just search my inbox for it.
>
> * Tagging: I've been using the tag feature,and it works really well. I'd
> like to see it advanced. Make into something as intuitive and easy and
> useful as the "Awesome Bar" has become in FFx 3.
Infrastructure below that I know David is working on. Important to the
quality that every reviewer and press-monger will key on when the 3.0
release comes out. _And_, has the potential to reduce subsequent bug
counts on the back end of the process - and fewer bugs = more time for
users and developers to focus on new and improved FEATURES!
Clint Talbert
> Clint Talbert wrote:
>> * Signature verifying. I have an email server that is xxx.foo.org but
>> its signature is xxx.bah.org I know this is ok, that the foo.org is
>> just a different virtual domain on that host. But Thunderbird has to
>> tell me several times a day about this. I'd love to be able to click
>> "OK, remember this" and be done with it.
>>
> I just want to pick on the issue you mentioned here. The above I think
> is an NSS issue and does the right thing IMO. Why is your client
> configured to access a "wrong" domain name? Shouldn't you have each
> account configured accordingly, including SMTP of course?
>
> Not sure why and when it asks you to confirm it, since you say "several
> times a day". Does this happen randomly? Or after a certain time? It
> doesn't make much sense right now, since either it warns you every time,
> or only once, or perhaps if you are using IMAP then every time the
> connection was dropped and established again. Which would match actually
> your next issue below...
The server's SSL signature is "www.fastmail.fm" the virtual domain I
use is "www.myfastmail.com" They both resolve to the same IP. TI get
an SSL warning box complaining every 15 minutes when it attempts to
establish a connection with the server, and what's worse, this seems to
happen on the UI thread because whatever I'm doing (typing this mail,
for instance) hangs until it displays the warning box about the SSL
mismatch between the signed SSL domain and the server name I'm using.
It doesn't have an option to "remember this" the way that firefox does
for similar problems with https sites.
However, in all the years I've had this particularly odd configuration
in place it actually *never* occurred to me to simply change the
"myfastmail.com" server name to the "fastmail.fm" server name (since
they resolve to the same IP). I just did that, and it works fine. I'll
bet you oodles of money I'll never see that warning again now.
Thanks for opening my eyes to this. :-)
So, I think this issue might be properly considered one more vote for
the "make it easier to add an account" feature. Especially since I
didn't get it right and I supposedly know what I'm doing. ;-)
Thanks again Eddy!
Clint
Kent James
>
> I look forward to the discussion!
I'd like to make sure that various spam-related improvements are
included in TB3. Here's a first pass at a list:
Must have:
1) Support for display of emails with uncertain status (bug 209890).
This would go a long way to improve the junk management, as you could
have a more aggressive junk cutoff number, as well as better choice of
emails to train.
2) Token pruning (bug 228675).
Should have:
1) More intelligent header tokenization. Current processing fills the
token database with lots of unique in-reply-to, message-id, plus
untokenized addresses in to: See for example bug 223716
2) Better support for headers set by upstream spam filters. This might
include filtering by SpamAssassin score, or including SpamAssassin
detected categories as tokens in the bayes algorithm.
Would like:
1) Use bayes filters for other features (bug 181866). It would be cool
to extend the bayes filter so that it could try to set tags after the
user has done some manual tagging.
2) Include explicit support for DNS-based blacklists (possibly bug 335008).
3) Better information display on message processing, including junk. It
should be possible to easily see why an email was marked/filtered. If
marked as junk or not junk, why? Filter, whitelist, user? What tokens
were important?
4) Better support for junk in filtering, including filtering by bayes
score, junk status, junkstatusorigin, plus ability to train emails as a
filter action.
Eddy Nigg (StartCom Ltd.)
in the knows isn't always to others...I'm glad I could help. So one
shouldn't hesitate to respond and find out more...
And to repeat that for others in this situation, the server name has
nothing to do with the account name. The address of the server may be
different then the domain name used in the email address.
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>
JoeS
> Peter Lairo wrote:
>> I disagree that RSS is important to Thunderbird. Reading RSS in a
>> three-pane e-mail program is painful
>
> A matter of taste (and monitor size).
>
> RSS support should either be improved or suppressed.
No need to wait for more monitor size if you use this extension: http://morelayoutsforthunderbird.mozdev.org/
Only available for branch builds though, because Dominspector is not publicity available as an addon.
Could someone please make Domi available in a trunk version.
-- JoeS
Ron K.
Joe, the extension works with Tb 2.0.0.9 Windows release build. If this
is because of DOMi, then it's good I had installed the Add-on, as I
would not have had a clue other wise.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
JoeS
> JoeS keyboarded, On 1/29/2008 8:32 PM :
>> Pascal Sartoretti wrote:
>>> Peter Lairo wrote:
>>>> I disagree that RSS is important to Thunderbird. Reading RSS in a
>>>> three-pane e-mail program is painful
>>>
>>> A matter of taste (and monitor size).
>>>
>>> RSS support should either be improved or suppressed.
>> No need to wait for more monitor size if you use this extension:
>> http://morelayoutsforthunderbird.mozdev.org/
>> Only available for branch builds though, because Dominspector is not
>> publicity available as an addon.
>>
>> Could someone please make Domi available in a trunk version.
>>
>> -- JoeS
>>
>
> Joe, the extension works with Tb 2.0.0.9 Windows release build. If this
> is because of DOMi, then it's good I had installed the Add-on, as I
> would not have had a clue other wise.
>
No, it doesn't require Domi to work, but further development to get it to work in trunk builds is held up by a lack
of Domi that works in trunk builds. Domi is only available as an extension for branch/release builds. The only way
you can get a fully working copy for trunk is if you can build it yourself and add the option.
Joe
Ron K.
> On 1/28/08 5:53 PM, _David Ascher_ spoke thusly:
>> * Release-defining features:
>> - an integrated calendaring feature, based on Lightning
>> - a better search experience, especially for message content searches
>> - a better overall user experience
>>
>> * Less user-visible but important goals include:
>> - Significant headway on getting rid of Mork and RDF
>> - A concerted effort to improving the extensions ecosystem for
>> Thunderbird, including refactorings, FUEL, developer documentation,
>> and user experience
>> - Better test coverage and performance metrics in place to support
>> refactoring goals
>>
>> There will be of course lots of other bug fixes and enhancements
>> (patches welcome ;-))
>
> Things I think would make Thunderbird rock:
>
> _Account setup library_
> Personally, I'd like to see an extensive library of account setup files.
> <http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>
> No Thunderbird user should ever have to type in the server name, port
> number, when setting up an account.
I have a strong disagreement here too. I do not think we should emulate
the way MS imposes a large quantity of files that are "Use Once" and
have them forever stored on the system. This was the case with Windows
9x. I have not explored Visa enough yet to say if this is still true
pertaining to account set up.
>> We're revise the schedule as we gain knowledge.
>
> I hope the eagerness to get something out the door within the year
> won't hurt the quality of the release. (e.g. Netscape 6)
>
One way I like how Mozilla products deal with internationalization is
the lean, clean files tree after install. Extensions by there single
server source are not as lean, many have all there l10n content bundled
into one common installer.
Ron K.
In the beginning of the Tb project David Tennsor was hosting the only Tb
Help pages himself. There was a follow on during the period before Tb
1.0 where a small team built a User Help website. During that early
period Firebird/Firefox had a similar problem, a lack of a local client
side help method.
For a long time Tb was using a local HTML page embedded in it's chrome
files for it's Start Page. We know that Tb is very capable of
displaying HTML pages in it's message pane. Given the Tb 3 tab
interface, I see an opening for doing some local client side help that
would use URI links to navigate a local HTML file package. The approach
would target a new tab so active user activity would not be cleared and
instantly restored on tab re-select. Down side being not callable when
a modal dialog has focus and prohibits additional actions till the
dialog is dismissed.
Ron K.
Nice opening for some User input. Currently we have some rather
essential extensions that would be far leaner if integrated into Tb.
Examples are NewsWorthy (No longer maintained, sadly. Provides UI for
some prefs), Folder Pane Tools (Move folders up/down in pane). The
Address Context add-on is adding a much needed right click menu. 'No New
Windows on Double Click' and 'Unselect Message' are two more projects
that enhance the user experience with ver small amounts of code. There
*.xpi files are 5KB and 11KB respectivly, of which the code it's self is
a small part of the files.
The extensions I nominate are some that addressed gaps in Tb development
that existed from the undersized development team. We users got good
feature additions which were very low on the priorities list. I think
we are over due for migrating some of those into the Tb code base where
I think they will benefit when the code base gets refactoring driven by
JS version development.
Ron K.
>
> Infrastructure below that I know David is working on. Important to
> the quality that every reviewer and press-monger will key on when the
> 3.0 release comes out. _And_, has the potential to reduce subsequent
> bug counts on the back end of the process - and fewer bugs = more time
> for users and developers to focus on new and improved FEATURES!
>
>> * Testing - We need test servers. You can't expect volunteer QA folk
>> to be willing to sacrifice their personal email accounts for testing.
>> Likewise, we also need to find a way to create an automated test
>> system. For example, it should be easy to run an automated POP and
>> IMAP and (maybe) NNTP automated test under the covers.
>>
>> * There are hundreds of Thunderbird Litmus
>> testcases(litmus.mozilla.org) we need to figure out who will own and
>> update these so that the MailCo team can begin using them for
>> testdays in order to get a good measurement of exactly where the
>> trunk stands in terms of quality.
Some good points here. From some Bug reading I did way back, We have
some NNTP networking bugs that got futured because fixes were seen as
dependent on some IMAP fixes, according to David B.'s annalists.
Related to Wayne's comment on User bug reporting is, we are
non-technical people who do not have the skills to help document the bug.
I do see a strong advantage to the proposal for MailCo to have protocol
testing servers. I think the triagers will be better equipped to
evaluate duplicate reports and steer the bugs to the right component for
attention. As for QA, the benefit is a consistent collection of
messages to aid spotting build to build regressions.
Finally, I think we are loosing a lot of User bug reports. We see lots
of postings in Tb support from users who do not know Bugzilla is the
place to report. We advise and give the URL, then see nothing
reported. In a few cases we get a User response indicateing reporting
site is too intimidating. To deal with this, I suggest adding a Help
menu item named "Report a Bug" that links to Bugzilla, and adding
Bugzilla to the Tb 'Start Page' so the reporting process has more
exposure to Users.
Ron K.
> David Ascher wrote:
>>
>> I look forward to the discussion!
>
> I'd like to make sure that various spam-related improvements are
> included in TB3. Here's a first pass at a list:
>
> Must have:
>
> 1) Support for display of emails with uncertain status (bug 209890).
> This would go a long way to improve the junk management, as you could
> have a more aggressive junk cutoff number, as well as better choice of
> emails to train.
>
> 2) Token pruning (bug 228675).
>
> Should have:
>
> 1) More intelligent header tokenization. Current processing fills the
> token database with lots of unique in-reply-to, message-id, plus
> untokenized addresses in to: See for example bug 223716
>
I have used the Java application that edits the training.dat and was
surprised at the volume of one-shot tokens that were created from header
data. It's very extensive, as virtually every header title has it's
values parsed for tokenization. Two examples:
X-pstn-levels: (S:48.65089/99.90000 R:95.9108 P:95.9108 M:94.1602 C:99.5902 )
X-pstn-settings: 4 (1.5000:1.5000) s gt3 gt2 gt1 r p m c
Either the filter is trained how to use that data or it should be
programed to skip those header items. Junk needs more immunity from
poisoning to preserve it's usefulness.
Chris Ilias
> Not sure I see exactly what this means. If an inventory of what and
> where with some comments, could help on that ( well, partially, as I
> wouldn't go into dev). If regards some undergoing doc already taking
> place, hm..
> If first, indicate a place as appropriate. I don't dear to say I'll do
> it, but can start..
Do you have a bugzilla.mozilla.org account? If there's anything you want
to contribute to on <http://www.mozilla.org/support/thunderbird/> or its
sub-pages (which is where Help-->Thunderbird_Help points to), file a bug
under the product:component of mozilla.org:www.mozilla.org.
Do you know HTML? You can go to the bottom of any of those pages, and
make the edits yourself and create a patch.
I'm also looking for people to build an Options panel reference.
<http://ilias.ca/blog/2007/04/please-help-with-thunderbird-options-documentation/>
Ideally, in my opinion, when Thunderbird 3 is released, mailco will have
an actual name, and Thunderbird will have its own web site; at which
point support docs should be moved to the new site.
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
Andreas Tscharner
> It's time to define the Thunderbird 3 plan. I've spent a fair bit of
[snip]
> 2. The reasons why people don't choose to use Thunderbird are varied,
> but two primary reasons appear to be: the lack of a built-in calendar
> integration (compared to Outlook for example), or a search experience
> that doesn't match that offered by competitors (gmail and Mail.app for
> example).
I agree here, but a calendar is only one thing. Being able to
synchronize it with your cell phone/PDA/Blackberry/etc. is IMHO almost
as important as the calendar; for enterprise _AND_ private users.
As there are many synchronization tools and frameworks out there, I
suggest to provide some sort of a generic synchronization interface (for
both: the calendar and the Thunderbird address book).
After having read all the other suggestions and propositions, one last
thing: Don't forget the Linux/Unix version!
Best regards and thank you
Andreas
--
Andreas Tscharner andreas....@metromec.ch
------------------------------------------------------------------------
And so at last the beast fell and the unbelievers rejoiced. But all was
not lost, for from the ash rose a great bird. The bird gazed down upon
the unbelievers and cast fire and thunder upon them. For the beast had
been reborn with its strength renewed, and the followers of Mammon
cowered in horror. -- The Book of Mozilla, 7:15
Chris Ilias
> Chris Ilias keyboarded, On 1/29/2008 12:52 PM :
>
>> Personally, I'd like to see an extensive library of account setup files.
>> <http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>
>> No Thunderbird user should ever have to type in the server name, port
>> number, when setting up an account.
>
> I have a strong disagreement here too. I do not think we should emulate
> the way MS imposes a large quantity of files that are "Use Once" and
> have them forever stored on the system.
This is where the add-ons browser helps. Instead of including the files
with the product, they get their own category in the add-ons browser.
The ISP files can be updated after the product is released, and the
account setup wizard will list the ISP files remotely. The only issue
removing the need to restart Thunderbird.
Chris Ilias
> I'm still gathering information about what the state of user
> documentation is, where the best resources are, how to best coordinate
> with the work of the Mozillazine community (and equivalents throughout
> the world), SUMO, etc.
For what it's worth, from the beginning, the intent of the Firefox
Support project was to build a system for Firefox, that other product
vendors could use for their products.
David Ascher
> I agree here, but a calendar is only one thing. Being able to
> synchronize it with your cell phone/PDA/Blackberry/etc. is IMHO almost
> as important as the calendar; for enterprise _AND_ private users.
> As there are many synchronization tools and frameworks out there, I
> suggest to provide some sort of a generic synchronization interface (for
> both: the calendar and the Thunderbird address book).
>
Hi Andreas, thanks for the post --
Synchronization of various kinds is, I agree, very important. However,
it feels so far like there is much more work to do before a complete
solution can be assembled for Thunderbird, with a variety of
incompatible synchronization schemes, uneven interop, etc. I do hope to
contact some of the relevant open source projects in the field to see if
there are some collaboration opportunities out there.
> After having read all the other suggestions and propositions, one last
> thing: Don't forget the Linux/Unix version!
>
Not likely!
--david
Ron K.
> On 1/29/08 11:17 PM, _Ron K._ spoke thusly:
>> Chris Ilias keyboarded, On 1/29/2008 12:52 PM :
>>
>>> _Account setup library_
>>> Personally, I'd like to see an extensive library of account setup
>>> files.
>>> <http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>
>>> No Thunderbird user should ever have to type in the server name,
>>> port number, when setting up an account.
>>
>> I have a strong disagreement here too. I do not think we should
>> emulate the way MS imposes a large quantity of files that are "Use
>> Once" and have them forever stored on the system.
>
> This is where the add-ons browser helps. Instead of including the
> files with the product, they get their own category in the add-ons
> browser. The ISP files can be updated after the product is released,
> and the account setup wizard will list the ISP files remotely. The
> only issue removing the need to restart Thunderbird.
OK, I now see where your going with this concept. I like lean, mean,
clean solutions.
David Ascher
> On 1/29/08 2:59 PM, _David Ascher_ spoke thusly:
>
>> I'm still gathering information about what the state of user
>> documentation is, where the best resources are, how to best coordinate
>> with the work of the Mozillazine community (and equivalents throughout
>> the world), SUMO, etc.
>>
>
> For what it's worth, from the beginning, the intent of the Firefox
> Support project was to build a system for Firefox, that other product
> vendors could use for their products.
>
repurposing some of their software, and learning from their experiences.
--david
Ron K.
The Sync need was one of the points made in the report written in Aug.
last year that Eddy Nigg sent to Michel Baker. I had taken a look
around and saw the biggest impediment is a lack of standardization in
the moble phone industry of a generic device interface. It's OK for
Noika to have proprietary features, but they set them selfs up to
responsibility to program drivers for every application that is a sync
source. Ditto for every other maker of mobile devices. If they have an
industry association, that may be a starting point for raising the issue
as it pertains to Tb being interested in interoperability of there
members with desktop/laptop computer softwares.
Norbert Püschel
> Norbert Püschel wrote:
>> What is more important than killing Mork is IMHO making the address book
>> extensible and adding a useful synchronisation interface to it. I'm sick
>> of programs like iTunes that only sync to Outlook. Writing addressbook
>> synchronisation is quite complicated with Thunderbird 2...
>
> Although it hasn't branched out here yet, we are looking at making the
> address book more extensible and improving its API at the same time as
> looking at killing Mork.
>
> Admittedly synchronisation is still one thing I need to look at on the
> API front, but we are thinking about it.
>
> Standard8
Synchronisation needs basically 3 things:
- a unique UUID per contact
- timestamps (last modification time) to detect changes easier
- a way to store custum data per contact if the sync partner needs to
store them
Norbert
mozil...@zindus.com
> Synchronisation needs basically 3 things:
> - a unique UUID per contact
Doesn't need to be universal (local is ok) but per AB object would be
useful: folder, list, contact.
> - timestamps (last modification time) to detect changes easier
Timestamps are one way of doing change detection - but not necessarily
the best. For one thing, time doesn't necessarily monotonically
increase on desktops and "best" is context dependent anyway.
The options seem to be:
1. Thunderbird defines what a change is. Which suggests API and/or
datastore support.
2. Thunderbird doesn't support change detection.
This is simpler for the core but then sync extensions decide
whether something has changed. A uniform mechanism for
iterating through and examining the AB objects would be handy,
which would make updates easier too.
(1) would be great but if time doesn't allow it then (2) could come
first and (1) layered in down the track.
It would also be nice if content (a field the user sees) were
distinguished from meta-data (access time, parent addressbook etc).
> - a way to store custum data per contact if the sync partner needs to
> store them
This is sorta kinda there now (though it's far from perfect):
http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbMDBCard.html#method_setStringAttribute
Transactional semantics (both in the AB datastore and external to it)
would be very helpful in maintaining integrity across the duration of a
sync.
Leni
Gervase Markham
> 2. Thunderbird already wraps together an e-mail client and an NNTP
> client. Although some prefer to read RSS feeds in their browser, many
> others (including me) think that reading RSS feeds is an activity which
> closely resembles reading NNTP newsgroups.
I agree. One simple change which would massively improve my RSS reading
experience would be the ability to decouple the "Show Message As..."
choice for different accounts. I want email displayed as "Simple HTML",
but RSS displayed as "Full HTML". At the moment, I use "Simple HTML"
throughout and reading blogs sucks because I don't see the images people
include.
But perhaps this is too detailed for a "planning" thread :-)
Gerv
Gervase Markham
> I'm not a software engineer, but I would expect that it would take us
> at least a month to play catchup on the trunk and fix the outstanding
> regressions. This would of course mean that our planned feature
> implementations for 0.9 and 1.0 would have to be postponed for said
> month.
I can't speak for David, but I would assume that if he wants to make
Calendar support in TB3 a key feature, he will be allocating at least
some of the time of his developers to making it happen. So that might
have some positive effect on any potential resource squeeze.
Gerv
Gervase Markham
> - Corporate users:
>
> 1. Sync the calendar with Exchange, without needing Outlook. Use OWA or a
> provider to sync with the Exchange calendar;
This is an enormous can of worms, IMO. Providing Exchange support (which
is not easy, as e.g. Evolution has found) means we are aiming at the
Enterprise market, which will want other features, MSIs, and an entirely
different level of support.
IMO, it would be better to explicitly define enterprise adoption as a
non-goal for MailCo in Thunderbird 3, and re-examine the situation for
Thunderbird 4.
Gerv
Gervase Markham
> * IMAP timeouts/network robustness. I've heard that this is in fact
> fixed on trunk, but have not been able to verify that. Everytime I
> switch networks, come back from sleep, Thunderbird goes out to pasture
> and spins for quite a while.
Glad I'm not the only one. (Well, not glad, but at least I'm not going
mad.) Before I complain about this, then, I'd better test trunk. But
none of my add-ons work :-((
Gerv
Gervase Markham
> It's time to define the Thunderbird 3 plan. I've spent a fair bit of
> I feel I've accumulated enough information to start this process.
>
> The long-term roadmap of Thunderbird is still in flux, but there are
> four high-level points which drive my thinking about Thunderbird 3:
>
> 1. Thunderbird's impact is proportional to its user count. Thus driving
> adoption is my primary concern. Our current user base is very
> significant (many millions of mostly quite satisfied users), but the
> number of possible users of Thunderbird is orders of magnitude greater
> than our current reach.
My speculation is that numerically, most people use either Outlook
Express or webmail for mail. Competing with OE isn't too hard, but
competing with webmail is harder to think about.
What can we tell people who ask: "Why should I install Thunderbird on my
desktop when I'm already using this nice, Ajaxy" (well, they wouldn't
say that, but you know what I mean) "email interface from Google/Yahoo?".
Ideas off the top of my head:
- Keep your email with you when not online (good for laptops; we need to
push IMAP more and make it easier to set up and use, and "fix" the
delete model)
- Better reliability and speed (e.g. in searching)
- "Unlimited" space (people still run out of space on some ISP-provided
webmails)
- Anti-spam (again, some ISP-provided webmail's not good here)
- Help with message organisation.
IMO, we need to push IMAP over POP, because if we use POP, people will
use the ability to log on and get their email via webmail from a
friend's house. And that'll be a showstopper.
David: do you have any thoughts in this area?
> 2. The reasons why people don't choose to use Thunderbird are varied,
> but two primary reasons appear to be: the lack of a built-in calendar
> integration (compared to Outlook for example), or a search experience
> that doesn't match that offered by competitors (gmail and Mail.app for
> example).
Hmm. I'm not sure the millions of webmail users are saying "I'd use a
desktop email client, but the calendaring sucks". (Although I do think
integrating calendaring is a good aim for TB3.) You may have a point
about search. I certainly find myself regularly wondering why on earth
TB's search is so slow.
(But then, even after what I wrote above, perhaps that's not a market we
are aiming at...)
> - alpha builds in Q1
> - beta builds without calendaring starting in Q2
As someone else said: if calendaring is release-defining, why have betas
without it? At least call them alphas...
Gerv
SanderG
> I agree. One simple change which would massively improve my RSS reading
> experience would be the ability to decouple the "Show Message As..."
> choice for different accounts. I want email displayed as "Simple HTML",
> but RSS displayed as "Full HTML". At the moment, I use "Simple HTML"
> throughout and reading blogs sucks because I don't see the images people
> include.
Mnenhy can do this already. It is sort of sleeping though.
Sander
ovidiu
local/client side normal one. But that was just a trigger (and maybe an
opportunity?) for raising a more general issue on the whole support and
help, not only regarding a help offline. The offline help is just an
obvious one, but not 'The' answer to support and guidance. Apparently
being a big one, it is debatable if it is going to significantly improve
the user experience. There should be a balance between the effort and
results there.
I am generally concerned about the whole support, help, tutorials,
forum, news, articles etc as it is an area that is usually a weakness in
open soft area and may be just a big plus for TB to develop a stronger
one or, why not, a better model. I think of it compared to commercial
soft where the direct customer service and support are a thing quite
unreachable in the 'open' area. But I think should develop more on this
in that wiki page..
The reason to generally discuss the support is also the "not
consolidated" or "spread around web" support that is kinda confusing and
frustrating for normal users and may even create a false impression of
the TB in terms of keeping in touch with users. Not only I can point to
various parallel help areas, but even in the same place, like these
news, there are many groups where you'll find people landing
accidentally and getting frustrated for what actually may be just a
matter of right place to go (some are more active, ,some not, who can tell?)
>
> For a long time Tb was using a local HTML page embedded in it's chrome
> files for it's Start Page. We know that Tb is very capable of
> displaying HTML pages in it's message pane. Given the Tb 3 tab
> interface, I see an opening for doing some local client side help that
> would use URI links to navigate a local HTML file package. The
> approach would target a new tab so active user activity would not be
> cleared and instantly restored on tab re-select. Down side being not
> callable when a modal dialog has focus and prohibits additional
> actions till the dialog is dismissed.
>
On the local html help, I would consider also the option of opening in a
separate window (simple one, not a duplicate of the whole tb) or even in
the browser along with the tab one. A matter of taste? I would rather be
concerned (also) about the way help will be updated. First came to mind
the normal extension like updating, so that it is independent of the
releases and can be frequently updated. In relation to this, there is
the issue of including it or not in the default pack or have it dld
separated (extension, again?) and can develop even more on this
(localization etc), but hey! I'm already packing it but still didn't got
the gift..
ovidiu
> On 1/29/08 5:28 PM, _ovidiu_ spoke thusly:
>> Not sure I see exactly what this means. If an inventory of what and
>> where with some comments, could help on that ( well, partially, as I
>> wouldn't go into dev). If regards some undergoing doc already taking
>> place, hm..
>> If first, indicate a place as appropriate. I don't dear to say I'll
>> do it, but can start..
>
> Do you have a bugzilla.mozilla.org account? If there's anything you
> want to contribute to on <http://www.mozilla.org/support/thunderbird/>
> or its sub-pages (which is where Help-->Thunderbird_Help points to),
> file a bug under the product:component of mozilla.org:www.mozilla.org.
Can file some things, can even ,file ,some general/big picture ones, but
I think I should get at least a better image of what I'm bugging, cause
it [doc and support..] is also about having support on several places
(your blog is one? ha! ;)), human resource spread around/parallel
effort, having lots of newsgroups with people falling in the wrong place
and, why not, eventually get an idea about the most efficient way of
supporting and guiding users.
>
> Do you know HTML? You can go to the bottom of any of those pages, and
> make the edits yourself and create a patch.
>
>
> I'm also looking for people to build an Options panel reference.
> <http://ilias.ca/blog/2007/04/please-help-with-thunderbird-options-documentation/>
>
>
> Ideally, in my opinion, when Thunderbird 3 is released, mailco will
> have an actual name, and Thunderbird will have its own web site; at
> which point support docs should be moved to the new site.
>
ones at first (getting along with FF etc..), but also as organizing
schema. And that may just be my very point. Not only the help (web or
offline), but a structured support and guidance for all the resources
out there. [For example, is kinda same as with extensions, having an
official place, but also a second one (mozdev..), having some good ones
not listed while some outdated or with some faults etc. and that is a
simpler case IMO and having already a central official place..]
I think with that wiki (or another way..) it is important to adress the
user docs and support as a whole.
Eddy Nigg (StartCom Ltd.)
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
ovidiu
fundamental difference between TB and FF that may also reflect on their
specific success, at least as user base. Meaning that support follows
usage and actions/processes:
To reduce it, FF does one simple job, browse, which by it's nature
is as simple as going to one/various places, while TB does several
things or maybe not so clear cut ones. Here TB involves setting and
understanding some tech things, nut also various manging data etc. Also
is a matter of importance of data. Mail is very important and needs kind
of "commitment", while browsing (to keep it simple..) can work or not,
and if not, just open another browser that you have around...
Given this usage, TB may be in more need of support that FF,
especially considering newbies or less computer literate..
[ i.e I think my mom could very well dld and install FF and just type
'ovidiu' in the search area and voila! Can this be in TB? Even if, let's
say, I give the setup (accounts etc..)? ..]
Simon Paquet
>> - Corporate users:
>>
>> 1. Sync the calendar with Exchange, without needing Outlook. Use OWA
>> or a provider to sync with the Exchange calendar;
>
> This is an enormous can of worms, IMO. Providing Exchange support
> (which is not easy, as e.g. Evolution has found) means we are aiming
> at the Enterprise market, which will want other features, MSIs, and
> an entirely different level of support.
In addition you'll need to play catchup with MS and you'll have to
support the full array of exchange features before large enterprises
would be ready to make the switch.
I think it is far more feasible to go after private users, small- and
medium-sized companies with perhaps up to 200-300 mail-accounts.
Cya
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Andreas Tscharner
> David Ascher keyboarded, On 1/30/2008 2:06 AM :
>>
>> Synchronization of various kinds is, I agree, very important.
>> However, it feels so far like there is much more work to do before a
>> complete solution can be assembled for Thunderbird, with a variety of
>> incompatible synchronization schemes, uneven interop, etc. I do hope
>> to contact some of the relevant open source projects in the field to
My personal favorite is OpenSync (http://www.opensync.org/) :-)
[snip]
> The Sync need was one of the points made in the report written in Aug.
> last year that Eddy Nigg sent to Michel Baker. I had taken a look
> around and saw the biggest impediment is a lack of standardization in
> the moble phone industry of a generic device interface. It's OK for
Well, SyncML comes to my mind. Almost all vendors claim that their
devices support it. And many devices support OBEX (not actually a
synchronization standard, but a way to get the data...)
Best regards
Archaeopteryx
> I agree. One simple change which would massively improve my RSS reading
> experience would be the ability to decouple the "Show Message As..."
> choice for different accounts. I want email displayed as "Simple HTML",
> but RSS displayed as "Full HTML". At the moment, I use "Simple HTML"
> throughout and reading blogs sucks because I don't see the images people
> include.
The ThunderBrowse extension (
https://addons.mozilla.org/en-US/thunderbird/addon/5373 ) is able to
open the Full HTML version if you click the webpage link in the header.
Unfortunately, the init of the extension doesn't work properly and so
the extension will start someday in the session to work.
The author told me that Thunderbird 3 will probably support cookies, so
i.e. answering bugmail in Thunderbird would be neat.
Archaeopteryx
> This is where the add-ons browser helps. Instead of including the files
> with the product, they get their own category in the add-ons browser.
> The ISP files can be updated after the product is released, and the
> account setup wizard will list the ISP files remotely. The only issue
> removing the need to restart Thunderbird.
Why show the default configuration stuff at all in the add-ons browser?
If the user adds a mail account, Thunderbird should demand the host of
the url for a mail configuration file like
http:://host/mailconfig.php?mailaddress
http:://host/mailconfig.xml
Later, Thunderbird should check regularly for updates of the mail
account configuration file.
ovidiu
> _Add-ons browser_
...
> The add-ons browsing experience should take place within Thunderbird.
> You can even use this to browse account setup files.
How would you do that? If I first install and then go to 'release
notes', which is normal web, I would just normally browse for other
related things. What about the extensions that are not listed in that
place or just made inhouse for limited use?
hm.. not that I have a better solution...
[ I always wonder, is changing the ".xpi" to ".xptb??" out of question?
maybe only as file extension (like jar and zip..) ]
Axel Hecht
Note that AMO integration just landed for Firefox 3, it might be worth
testing how well that works for Thunderbird. It might just work, not
sure how much the add-ons manager shares that stuff.
The other suggestion in the corresponding bug is to create a separate
mimetype for each app supported by AMO, and to make that app register
itself with the OS for that. Which, apart from wildly running over
mimetype registration issues, doesn't sound too bad for me. I don't
remember where that bug is at these days, though.
axel
Robert Kaiser
> Admittedly synchronisation is still one thing I need to look at on the
> API front, but we are thinking about it.
I think we should look into using/supporting the (apparently)
cross-platform OpenSync framework for synchronization, as in that case
we don't have to provide the interfaces to different foreign formats
ourselves, only an interface to the library/framework.
Robert Kaiser
Robert Kaiser
> Note that AMO integration just landed for Firefox 3, it might be worth
> testing how well that works for Thunderbird. It might just work, not
> sure how much the add-ons manager shares that stuff.
Mossop said he wants to get it working for SeaMonkey, Thunderbird and
Sunbird once it works well enough for FF3, but he first wants/needs to
meet the FF3 deadlines with this work. As we're probably all planning on
1.9-based releases for a later date than FF3, we all should be able to
get that integration pane for this trunk release cycle.
Robert Kaiser
Wayne Mery
> Clint Talbert wrote:
>> * IMAP timeouts/network robustness. I've heard that this is in fact
>> fixed on trunk, but have not been able to verify that. Everytime I
>> switch networks, come back from sleep, Thunderbird goes out to pasture
>> and spins for quite a while.
Gerv, Good that you're going to test trunk because if you are using
latest branch it already has one of the big fixes as of FF and TB
2.0.0.8/.9 -- Bug 213637 – Mozilla runs at ~100% cpu usage after
network connection is interrupted, changing network/LAN, switching from
wireless to non-wireless, undocking.
I'm not sure what Clint refers to but there's not much else in the
wings. Though I've probably missed one or two and there certainly some
areas of trunk with fixes that I don't pay attention to. Still, I have
my doubts that trunk might help you.
Here are some big bugs ...
fixed, trunk-only - Bug 404059 – connection to t-mobile hotspot startup
page takes very long
open, trunk-only - Bug 398695 – Minefield can't load pages after you
switch your network interface
UNCO - Bug 411258 – FF could not connect to the internet after wake up
from a sleep on Windows Vista.
fixed1.8.1.12 - Bug 405440 – IMAP cache broken if the message download
is not finished due to user interaction
... and there are of course other open networking and imap bugs.
> Glad I'm not the only one. (Well, not glad, but at least I'm not going
> mad.) Before I complain about this, then, I'd better test trunk. But
> none of my add-ons work :-((
>
> Gerv
override version via NTT http://www.oxymoronical.com/web/firefox/nightly
Robert Kaiser
> The server's SSL signature is "www.fastmail.fm" the virtual domain I use
> is "www.myfastmail.com" They both resolve to the same IP. TI get an SSL
> warning box complaining every 15 minutes when it attempts to establish a
> connection with the server, and what's worse, this seems to happen on
> the UI thread because whatever I'm doing (typing this mail, for
> instance) hangs until it displays the warning box about the SSL mismatch
> between the signed SSL domain and the server name I'm using. It doesn't
> have an option to "remember this" the way that firefox does for similar
> problems with https sites.
On trunk, the core toolkit contains a quite good exception solution for
that, please try with trunk nightlies if what you want already works
reasonably well.
Robert Kaiser
Greg K Nicholson
> Hmm. I'm not sure the millions of webmail users are saying "I'd use a
> desktop email client, but the calendaring sucks". (Although I do think
> integrating calendaring is a good aim for TB3.)
I'd use *Thunderbird* but Evolution integrates with Gnome's panel. And
every Sunbird user is an example of "I'd use a calendar (oh, hey, look,
it does email too)".
You are right about webmail vs. a client, though.
--
Greg
Robert Kaiser
> Ron K. wrote:
>> David Ascher keyboarded, On 1/30/2008 2:06 AM :
>>> Hi Andreas, thanks for the post --
>>>
>>> Synchronization of various kinds is, I agree, very important.
>>> However, it feels so far like there is much more work to do before a
>>> complete solution can be assembled for Thunderbird, with a variety of
>>> incompatible synchronization schemes, uneven interop, etc. I do hope
>>> to contact some of the relevant open source projects in the field to
>
> My personal favorite is OpenSync (http://www.opensync.org/) :-)
>
> [snip]
>> The Sync need was one of the points made in the report written in Aug.
>> last year that Eddy Nigg sent to Michel Baker. I had taken a look
>> around and saw the biggest impediment is a lack of standardization in
>> the moble phone industry of a generic device interface. It's OK for
>
> Well, SyncML comes to my mind. Almost all vendors claim that their
> devices support it. And many devices support OBEX (not actually a
> synchronization standard, but a way to get the data...)
OpenSync support SyncML as one of the output formats - if we support
OpenSync, then we should be able to just do the synchronization with any
app/format supported by that library.
BTW, see https://bugzilla.mozilla.org/show_bug.cgi?id=303963 for the
OpenSync support bug.
Robert Kaiser
DanKegel
> 3. In addition, Thunderbird's codebase has a fair bit of technical debt
> due to insufficient resourcing over the years, which has led to a
> codebase which has too many scary bits, not enough test coverage
... and lots of crashes, and horrifically bad crash recovery.
Time is short. Competitors will surely catch up on the few things
Thunderbird is better at. You'd better make Thunderbird rock solid
reliable by then, or you are history.
There's some good discussion on this at LWN in response to your post.
In particular, here are three posts pleading for greater reliability:
http://lwn.net/Articles/266938/
The one absolutely critical thing to fix for Thunderbird is
reliability of data
storage and particularly indexes. I support a few friends/family who
use
Thunderbird and they frequently find that messages seem to disappear
-
this is usually fixable by deleting *.msf files, but try talking this
through
with someone on the phone or IM! Thunderbird needs to prevent such
problems completely if possible through more reliable storage design,
or at least recognise such problems and automatically fix them...
http://lwn.net/Articles/266946/
Data storage reliability could be dramatically improved by dropping
mbox for maildir at last ... maildir support has been requested since
2000
but unfortunately it seems not to be on thunderbird authors radar,
even after all the mbox robustness problems people predicted then
materialised. https://bugzilla.mozilla.org/show_bug.cgi?id=58308
http://lwn.net/Articles/267166/ (my post)
Thunderbird crashes monthly for my wife, and when
it does, she has to remove upwards of 10,000 duplicate messages
from inbox, and go through a complicated ritual of compressing
mail folders and resetting every single fucking folder's sort
options by hand. This is a serious pain when you have
200 folders. I swear to god she loses 8 hours of work
each time this happens. And she's no novice.
I think one key to this is to get more forceful about
enabling the crash feedback widget. Many users simply
don't understand how important that is, nor should they have to.
If Thunderbird notices it has crashed three times without that
turned on, it should get very persuasive about enabling it.
And if the crashes persist over months, the client should set a
"user very angry" flag in the crash report.
Thanks,
Dan Kegel
Free software quality curmudgeon