Thunderbird 3 Planning

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.

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
0
David
1/28/2008 10:53:49 PM
mozilla.dev.apps.thunderbird 3464 articles. 0 followers. Post Follow

189 Replies
1834 Views

Similar Articles

[PageSpeed] 7

Hi David,

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:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 


David Ascher wrote:
> 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.
>
> 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
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-thunderbird@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>   

0
Eddy
1/28/2008 11:18:17 PM
Hi David,

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:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 


David Ascher wrote:
> 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.
>
> 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
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-thunderbird@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>   

0
Eddy
1/28/2008 11:18:17 PM
Hi David,

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:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 


David Ascher wrote:
> 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.
>
> 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
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-thunderbird@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>   

0
Eddy
1/28/2008 11:18:17 PM
David Ascher wrote:
> 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
0
Sergey
1/28/2008 11:57:34 PM
> - 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).

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
0
Gary
1/29/2008 12:02:19 AM
Sergey Yanovich wrote:
> 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 :
Thanks for the note.  I'm certainly interested in figuring out the 
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

0
David
1/29/2008 12:05:57 AM
David Ascher wrote:
> 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
0
Myk
1/29/2008 12:08:37 AM
Myk Melez wrote:
> David Ascher wrote:
>   
>> 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.
>   
Gee, I'm that transparent. ;-)

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

0
David
1/29/2008 12:19:14 AM
Myk Melez wrote:
> David Ascher wrote:
>> 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

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


0
JoeS
1/29/2008 1:56:46 AM
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...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
1/29/2008 2:07:08 AM
JoeS wrote:
> 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
0
Myk
1/29/2008 2:16:22 AM
Eddy Nigg (StartCom Ltd.) wrote:
> 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...
>
That's just a minor bug, but my point is that core bugs that break Tbird don't seem to get the attention that they deserve.
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.


0
JoeS
1/29/2008 2:17:55 AM
JoeS wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
>   
>> 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...
>>
>>     
> That's just a minor bug, but my point is that core bugs that break Tbird don't seem to get the attention that they deserve.
> 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.
>   
All of which is why we're starting MailCo, recruiting full-time devs as 
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

0
David
1/29/2008 2:31:24 AM
David Ascher wrote:
> * 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
0
Pascal
1/29/2008 8:57:11 AM
David Ascher pisze:
> Sergey Yanovich wrote:
>> 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 :
> Thanks for the note.  I'm certainly interested in figuring out the 
> 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
> 

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
0
Arivald
1/29/2008 9:40:13 AM
David Ascher wrote on 28. Jan 2008

> * 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 drasti
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 branc
to enable us to fully support TB2. All changes are cross-committe
to the trunk as well, but due to API and other architectural change
there exist several pretty serious regressions on the trunk that w
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 branc
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 u
at least a month to play catchup on the trunk and fix the outstandin
regressions. This would of course mean that our planned featur
implementations for 0.9 and 1.0 would have to be postponed for sai
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. I
would also mean that we need more manpower in the testing community
but I'm not very concerned about that, since the inclusion into TB
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 ho
much we want to support it, given that those guys will most likel
release alpha or beta releases of SM2 during that timeframe as well

Simo

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
0
Simon
1/29/2008 11:09:06 AM
David Ascher wrote:
> 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
0
Pascal
1/29/2008 1:04:02 PM
Pascal Sartoretti wrote on 29. Jan 2008

>> 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).

This is already possible if you install the Lightning extension

Simo

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
0
Simon
1/29/2008 1:52:53 PM
Simon Paquet wrote:
>> 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
0
Pascal
1/29/2008 2:15:03 PM
Pascal Sartoretti wrote:
> 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
0
Robert
1/29/2008 2:21:23 PM
Simon Paquet wrote:
> 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
0
Robert
1/29/2008 2:28:07 PM
David Ascher wrote:
> * 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
0
Robert
1/29/2008 2:32:05 PM
On Mon, 28 Jan 2008 14:53:49 -0800, David Ascher wrote:

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



0
SanderG
1/29/2008 3:19:53 PM
Robert Kaiser wrote on 29. Jan 2008

>> 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-commi
policy of mozilla/calendar

We can't just switch to the trunk. We have a few hundred thousand user
on TB2 and we can't just let them hang out in the open while TB3 i
still in alpha, beta or RC stage

So at least until Lightning 1.0 is released (probably even longer) w
will stay on the branch or at least commit a major part of ou
development resources there

Simo

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
0
Simon
1/29/2008 3:20:50 PM
Robert Kaiser wrote:
> 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
0
Pascal
1/29/2008 3:21:32 PM
SanderG wrote on 29. Jan 2008

> 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 i
absolutely impossible to achieve this in the TB3 timeframe that Davi
proposed

In addition the only viable open source solution that could be use
to quickly add Exchange support to Thunderbird and Lightning (libmapi
can not be used because of license imcompatibilities (libmapi use
GPLv3, while we use the MPL/LGPL/GPL tri-license)

Unless the libmapi developers change their license, we would have t
implement this stuff from scratch, which would probably take at leas
1-2 years to reach a "basic support"-milestone

Simo

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
0
Simon
1/29/2008 3:30:50 PM
Pascal Sartoretti on 29.01.2008 09:57 wrote:
> David Ascher wrote:
>> * Release-defining features:
> 
> I would add RSS to this list 

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
0
Peter
1/29/2008 3:44:52 PM
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.
0
Pascal
1/29/2008 5:00:35 PM
Simon Paquet wrote:
> 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
0
Mark
1/29/2008 5:25:36 PM
Pascal Sartoretti wrote:
> Robert Kaiser wrote:
>> 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
More or less answering that:
    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.
0
ovidiu
1/29/2008 5:36:55 PM
David Ascher schrieb:
> 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.
> 
> 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

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
0
ISO
1/29/2008 5:40:56 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.
It is always a matter of what you are looking for. If  i.e. TB would 
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.
0
ovidiu
1/29/2008 5:49:39 PM
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 ;-))

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
0
Chris
1/29/2008 5:52:00 PM
Mark Banner wrote on 29. Jan 2008

>> 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) wa
that we would release 1.0 somewhere in October or November 2008 an
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 no
work with TB3. I was just saying that making that possible ha
consequences with regards to when we can push out our next releases

If it was just about aligning our releases with Thunderbird, I'm sur
we could accomodate, but we'll also have to look at what Sun wants t
do with OpenOffice 3.0 (Sun funds roughly 60% of our devs) and whethe
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 developer
and testers to work in parallel on branch and trunk. And more wor
means less fixes in a given timeframe, which results in a longe
preparation time for a release if we assume a fixed developer headcount

Simo

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
0
Simon
1/29/2008 5:58:39 PM
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
0
Mark
1/29/2008 6:02:25 PM
Chris Ilias wrote:
> _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
0
Mark
1/29/2008 6:04:51 PM
Norbert P�schel wrote on 29. Jan 2008

>> * 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.
- The release cycles of Lightning and TB differ significantly at th
  moment. TB will probably only push out one major release ever
  12-18 months, while Lightning is currently being updated ever
  4 month
- We could still release updates of Lightning if Lightning would stil
  be treated as an extension internally and major TB releases coul
  contain an update.rdf file pointing to addons.mozilla.org where w
  would release updates to Lightnin

Simo

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
0
Simon
1/29/2008 6:08:24 PM
On 29.01.2008 12:04, Mark Banner wrote:

 --- Original Message ---

> Chris Ilias wrote:
>> _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

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. ;-)

-- 
Jay Garcia Netscape Champion
UFAQ - http://www.UFAQ.org
0
Jay
1/29/2008 6:16:02 PM
David Ascher wrote:
> 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.
>
> 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
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)?
0
ovidiu
1/29/2008 7:42:32 PM
> 
> 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
0
Gary
1/29/2008 7:51:24 PM
Hi,

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

David Ascher wrote:
> 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.
> 
> 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
> _______________________________________________
> dev-apps-calendar mailing list
> dev-apps-calendar@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-calendar

0
Daniel
1/29/2008 7:53:06 PM
Simon Paquet wrote:
> 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.
AFAIK porting libmapi is not that easy, because it's coupled to the
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
0
Daniel
1/29/2008 7:54:29 PM
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. 

>     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

0
David
1/29/2008 7:59:34 PM
Daniel Boelzle wrote:
> 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

0
David
1/29/2008 8:11:40 PM
Jay Garcia wrote:
>
> 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
0
David
1/29/2008 8:27:54 PM
David Ascher wrote:
> 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
0
Mark
1/29/2008 8:39:14 PM
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.

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.
0
mozilla
1/29/2008 8:43:28 PM
I really value all of these suggested features & bug fixes, but I worry 
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

0
David
1/29/2008 9:48:12 PM
Mark Banner wrote:
> David Ascher wrote:
>> 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
Which leads to the idea of some extensions being more important if 
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.
0
ovidiu
1/29/2008 9:50:58 PM
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? 
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
0
Kent
1/29/2008 9:56:41 PM
Kent James wrote:
> 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? 
>   
Sure -- one big concern of course is that for each optional component, 
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

0
David
1/29/2008 10:09:53 PM
David Ascher wrote:
> 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.
As I am concerned mostly on the user side, not dev, there is even more 
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
>
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..

ovidiu
0
ovidiu
1/29/2008 10:28:27 PM
David Ascher wrote:
...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


0
Clint
1/29/2008 10:45:30 PM
ovidiu wrote:
>> 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

0
David
1/29/2008 10:49:09 PM
Pascal Sartoretti wrote:
  > 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.
0
Bed
1/29/2008 10:59:10 PM
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...
> * 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:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
1/29/2008 11:38:54 PM
On 1/29/2008 5:45 PM, Clint Talbert wrote:
> 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!

> * 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.
0
Wayne
1/30/2008 12:25:14 AM
Eddy Nigg (StartCom Ltd.) wrote:
> 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...
Sorry, I didn't explain this real well.
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
0
Clint
1/30/2008 12:30:57 AM
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

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.




0
Kent
1/30/2008 12:44:36 AM
Hey, you are welcome! Which shows to me, that what is obvious to the one 
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:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 


Clint Talbert wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
>   
>> 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...
>>     
> Sorry, I didn't explain this real well.
> 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
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-thunderbird@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>   

0
Eddy
1/30/2008 1:21:25 AM
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

0
JoeS
1/30/2008 1:32:09 AM
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.

-- 
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!
0
Ron
1/30/2008 3:32:21 AM
Ron K. wrote:
> 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

0
JoeS
1/30/2008 3:47:37 AM
Chris Ilias keyboarded, On 1/29/2008 12:52 PM :
> 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 ;-))
>
> 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.

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.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
1/30/2008 4:17:27 AM
David Ascher keyboarded, On 1/29/2008 5:49 PM :
> ovidiu wrote:
>>> 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
>

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.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
1/30/2008 4:39:28 AM
David Ascher keyboarded, On 1/29/2008 5:09 PM :
> Kent James wrote:
>> 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?   
> Sure -- one big concern of course is that for each optional component, 
> 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
>

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.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
1/30/2008 5:12:25 AM
Wayne Mery keyboarded, On 1/29/2008 7:25 PM :
> On 1/29/2008 5:45 PM, Clint Talbert wrote:
>> 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.
>
> [snip]
>
> 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.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
1/30/2008 5:58:43 AM
Kent James keyboarded, On 1/29/2008 7:44 PM :
> 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.

-- 
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!
0
Ron
1/30/2008 6:13:27 AM
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.

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
0
Chris
1/30/2008 6:48:37 AM
David Ascher wrote:
> 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.tscharner@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
0
Andreas
1/30/2008 6:51:17 AM
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.
-- 
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
0
Chris
1/30/2008 6:52:58 AM
Andreas Tscharner wrote:
> 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
0
David
1/30/2008 7:06:12 AM
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.
-- 
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
0
Chris
1/30/2008 7:06:20 AM
Chris Ilias wrote:
> 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.
>   
Yes, I've had good email chats w/ David about the possibilities of 
repurposing some of their software, and learning from their experiences.

--david
0
David
1/30/2008 7:11:15 AM
Chris Ilias keyboarded, On 1/30/2008 1:52 AM :
> 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.

-- 
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!
0
Ron
1/30/2008 7:12:05 AM
David Ascher keyboarded, On 1/30/2008 2:06 AM :
> Andreas Tscharner wrote:
>> 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


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.

-- 
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!
0
Ron
1/30/2008 7:31:18 AM
Mark Banner schrieb:
> 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
0
ISO
1/30/2008 7:38:40 AM
Norbert P�schel wrote:
> 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
0
mozilla
1/30/2008 8:46:54 AM
Pascal Sartoretti wrote:
> 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
0
Gervase
1/30/2008 10:22:16 AM
Simon Paquet wrote:
> 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
0
Gervase
1/30/2008 10:24:11 AM
SanderG wrote:
> - 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
0
Gervase
1/30/2008 10:26:04 AM
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.

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
0
Gervase
1/30/2008 10:30:55 AM
David Ascher wrote:
> 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.
> 
> 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
0
Gervase
1/30/2008 10:39:59 AM
On Wed, 30 Jan 2008 10:22:16 +0000, Gervase Markham wrote:
> 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

0
SanderG
1/30/2008 11:02:32 AM
Ron K. wrote:
> David Ascher keyboarded, On 1/29/2008 5:49 PM :
>> ovidiu wrote:
>>>> 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
>>
>
> 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.
I have to say that I pointed out documentation as there is none for the 
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..
0
ovidiu
1/30/2008 11:08:47 AM
Chris Ilias wrote:
> 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.
ok, but I think this is more of a general thing that I'm looking for. 
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.
may just do that
>
>
> I'm also looking for people to build an Options panel reference.
> <http://ilias.ca/blog/2007/04/please-help-with-thunderbird-options-documentation/> 
>
I'll go there and see what I can do
>
> 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.
>
and by that time, new issues will rise. Let's say they are marketing 
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.
0
ovidiu
1/30/2008 11:34:16 AM
Gervase Markham wrote:
> SanderG wrote:
>   
>> - 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.
>
>   
Correct! I think this is the goal without saying it explicitly ;-)

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
1/30/2008 11:49:00 AM
David Ascher wrote:
> Chris Ilias wrote:
>> 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.
>>   
> Yes, I've had good email chats w/ David about the possibilities of 
> repurposing some of their software, and learning from their experiences.
>
> --david
I dear to say that this [support] is one of the very things that show a 
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..)? ..]
0
ovidiu
1/30/2008 11:51:23 AM
Gervase Markham wrote on 30. Jan 2008

>> - 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 t
support the full array of exchange features before large enterprise
would be ready to make the switch

I think it is far more feasible to go after private users, small- an
medium-sized companies with perhaps up to 200-300 mail-accounts

Cy
Simo

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
0
Simon
1/30/2008 12:24:38 PM
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...)

Best regards
	Andreas
-- 
Andreas Tscharner                          andreas.tscharner@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
0
Andreas
1/30/2008 12:29:40 PM
Gervase Markham wrote:
> 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.
0
Archaeopteryx
1/30/2008 12:34:40 PM
Chris Ilias wrote:
> 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.
0
Archaeopteryx
1/30/2008 12:48:18 PM
Chris Ilias wrote:
> _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..) ]
0
ovidiu
1/30/2008 1:13:28 PM
ovidiu wrote:
> Chris Ilias wrote:
>> _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..) ]

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
0
Axel
1/30/2008 2:05:57 PM
Mark Banner wrote:
> 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
0
Robert
1/30/2008 2:31:24 PM
Axel Hecht wrote:
> 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
0
Robert
1/30/2008 2:36:16 PM
On 1/30/2008 5:30 AM, Gervase Markham wrote:
> 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
0
Wayne
1/30/2008 2:38:53 PM
Clint Talbert wrote:
> 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
0
Robert
1/30/2008 2:41:49 PM
Andreas Tscharner wrote:
> 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
0
Robert
1/30/2008 2:45:27 PM
> 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

0
Greg
1/30/2008 2:45:27 PM
On Jan 28, 2:53 pm, David Ascher <david.asc...@gmail.com> wrote:
> 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
0
DanKegel
1/30/2008 2:51:42 PM
Robert Kaiser wrote:
> Axel Hecht wrote:
>> 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.

Personally I think the add-ons browsing functionality within the 
extension manager is a great idea towards solving the "how do i install 
extensions in Thunderbird without saving it to the hard disk and 
installing it manually" hassle.

More previous information here:

http://wiki.mozilla.org/Thunderbird:Extension_Installation

Gary Kwong
0
Gary
1/30/2008 5:08:53 PM
ovidiu keyboarded, On 1/30/2008 6:08 AM :
> Ron K. wrote:
>> David Ascher keyboarded, On 1/29/2008 5:49 PM :
>>> ovidiu wrote:
>>>>> 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
>>>
>>
>> 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.
> I have to say that I pointed out documentation as there is none for 
> the 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..


I have never liked how Tb lacks local offline help.  I see a way to deal 
with independent updating between releases.  Since Tb handles JAR files, 
the HTML help documents could be archived into a Help.Jar.  Downside is 
this would need expansion of the update code and the Add-on Manager to 
do the install. The essence of this is a behavior that is consistent 
with Add-on and Theme updating. 

Beyond that I suspect that some code would be needed to support 
extracting content from the Help.Jar and steering the content to the 
display. I would not want a simple window to be modal. The window should 
be minimizable to permit seeing other windows being tutored by the Help.

-- 
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!
0
Ron
1/30/2008 6:09:07 PM
Chris Ilias pisze:
> 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.

It could be very useful and important for home users.

Setting up accounts is key area where normal users have biggest problems, second one is recovering mail after random failures, this is also one of biggest webmail advantages over traditional desktop clients.

>> 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.

Why not to tie up this with l10n process, exactly like it is happening with bookmarks and services in Firefox?
Providing few bundled (~5?) popular ISP configurations should not make the problem and should be a huge improvement of first time UX; in the same time there could be second, optional, server side list of configurations for not bundled ISPs which will sign some sort of cooperation agreement with MailCo.


Stef

-- 
Aviary.pl l10n team
http://www.aviary.pl

0
Stefan
1/30/2008 6:33:37 PM
Stefan Plewako wrote:
> Chris Ilias pisze:
>> 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.
> 
> It could be very useful and important for home users.
> 
> Setting up accounts is key area where normal users have biggest 
> problems, second one is recovering mail after random failures, this is 
> also one of biggest webmail advantages over traditional desktop clients.
> 
>>> 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.
> 
> Why not to tie up this with l10n process, exactly like it is happening 
> with bookmarks and services in Firefox?
> Providing few bundled (~5?) popular ISP configurations should not make 
> the problem and should be a huge improvement of first time UX; in the 
> same time there could be second, optional, server side list of 
> configurations for not bundled ISPs which will sign some sort of 
> cooperation agreement with MailCo.

They are. It's just that moco didn't invest manpower in organizing the 
files and getting permissions and sign-in to those configurations across 
locales.

Which policy mailco is going to run for this is up to mailco, and how 
much resources they have. It's surely nothing to be done at the side.

Axel
0
Axel
1/30/2008 6:41:53 PM
On 2008-01-30 07:12, Ron K. wrote:
> 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.

I haven't used the extensions bug it doesn't sound very sensible including "bug 
fix" extensions like the "No New Windows on Double Click" ext. That issue is was 
a fixed long time ago in the release builds.

For things that are clearly bugs I would encourage extension authors (and 
others) to provide patches for the bugs instead. Obviously some functionality is 
not the kind of users in general would want, and such things should remain as 
extensions.

  -Magnus

0
Magnus
1/30/2008 7:25:34 PM
On 2008-01-30 16:41, Robert Kaiser wrote:
> Clint Talbert wrote:
>> 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.

Though setting up the exception is quite the challenge currently, see 
https://bugzilla.mozilla.org/show_bug.cgi?id=399174

  -Magnus

0
Magnus
1/30/2008 7:28:49 PM
On 30.01.2008 13:24 �Simon Paquet� wrote
> 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
> 
Big YES!!
It's NOT running behind MS, it's to understand the needs of the current 
users
-- as Simon said: private users, small- and medium-sized companies, the 
creativity of the community
-- as expressed with this thread about those many ideas to improve 
functionality and quality.

NOT catching up the number of users is the main goal -- here MS will be 
the #1 (maybe for a unforeseeable timeframe) ...

....the goal has to be: MailCo is the #1 with:

  * best package to act as the personnel information center to serve for 
other 'participant' (eg. account infos, contacts, events, todos, ... )
  * best usability with easy to use documentation (not only 
manual/web/.. but all channels to answer users questions etc)
  * the best 'kernel' communication system which supports todays 
technics and
  * best openness to be expendable for new technics/protocols etc
  * best platform for application addons --- for users (see FX vs TB 
usability) and developers

  last NOT least:
  * best quality!

BUT time to market is essential! A discussion about quality and release 
cycle needs to hold in mind:
Not 100% is the goal, but RESOURCES to react on experience combined with 
a proven quality management for fast and good paced releases, that has 
to be the goal.

Customers love functionality combined with quality! That's why Firefox wins!

G�nter


0
gNeandr
1/30/2008 7:38:53 PM
On 2008-01-30 16:45, Greg K Nicholson wrote:
>> 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.

Absolutely - of the "normal" people I get mail from a huge part is using 
webmail. And I'm not even talking about gmail and other semi-working webmails 
but the old fashion kind... There is a big market to be had there, I imagine.

IMAP is definitely one way to gradually move them over, easier account setup 
another. And then spreading the word of course. A real spreadthunderbird, 
anyone? https://bugzilla.mozilla.org/show_bug.cgi?id=381791

  -Magnus
0
Magnus
1/30/2008 7:45:46 PM
On 2008-01-29 22:27, David Ascher wrote:
> However, I do like the idea outlined in
> http://wiki.mozilla.org/Thunderbird:Easy_Account_Setup#Hosted_Web_Service

Me too, I'm definitely up for doing some work to make this happen!

Account setup could get as simple as giving name and email, then the wizard 
could check if we know the "good settings" for the domain, fill them in and let 
the user hit finish.

Perhaps somewhere there could be UI for sharing settings for your domain with a 
click or two.

  -Magnus
0
Magnus
1/30/2008 8:02:21 PM
Ron K. wrote:
> ovidiu keyboarded, On 1/30/2008 6:08 AM :
>> Ron K. wrote:
>>> David Ascher keyboarded, On 1/29/2008 5:49 PM :
>>>> ovidiu wrote:
>>>>>> 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
>>>>
>>>
>>> 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.
>> I have to say that I pointed out documentation as there is none for 
>> the 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..
>
>
> I have never liked how Tb lacks local offline help.  I see a way to 
> deal with independent updating between releases.  Since Tb handles JAR 
> files, the HTML help documents could be archived into a Help.Jar.  
> Downside is this would need expansion of the update code and the 
> Add-on Manager to do the install. The essence of this is a behavior 
> that is consistent with Add-on and Theme updating.
> Beyond that I suspect that some code would be needed to support 
> extracting content from the Help.Jar and steering the content to the 
> display. I would not want a simple window to be modal. The window 
> should be minimizable to permit seeing other windows being tutored by 
> the Help.
>
[OK, non modal, just like compose, addons etc..]

Be it that or like an extension, is not for me to say as I don't really
understand the deep app and how easy or not something is. It is
important IMHO to have a very easy way of creating and distributing
help, html mostly, so that extensions may just drop their peace of help
in the same 'place'. [Is it doable as just for having html and little
bit of a hook to be understood as 'help'?]

If, say, there would be a window/pane (tab etc.) dedicated to this, it
may just read more than one 'help', which may just show as folders or
subfolders etc (just to use structures already defined..) corresponding
to main help and extensions helps. That may even allow extra help to be
added from 3rd party dev or may end up in a modular help that can be
even more independently updated: basic help, getting started, tutorials
etc.. Think of the TB and lightning ,going together but upgrading at
different pace and also upgrading help at different pace.

Saying that leads me to an even 'bolder' idea: What if the help
page/pane/window would just look more or less like a bookmark one,
having added the corresponding links to various help files, *local and
web*, course, showing that with something like online/offline mode. In
this way it can be even more flexible for extension devs or the 3rd
party... and may even mix various resources.[ Should I dear to say even
grouping /organizing them etc? What is the relation to FF or other
browser bookmarks? the ideal AB as in another thread..?.. ]

ok, ok, stop!
0
ovidiu
1/30/2008 9:30:16 PM
Norbert P�schel wrote:
> Synchronisation needs basically 3 things:

As someone who is working on both the AB rewrite and demorkification for 
AB (bugs 413260 and 382876, respectively), let me address these points:

> - a unique UUID per contact
It is planned to be almost there: we can guarantee a UUID for all cards 
within the database and a UUID for the database/directory itself. So 
it's a tupled-UUID; is this sufficient?

> - timestamps (last modification time) to detect changes easier

This already exists (nsIAbCard.lastModifiedDate, er, 
nsIAbCard.getProperty("LastModifiedDate") :-) ), but it is up to the 
user of the card to update it last I checked.

> - a way to store custum data per contact if the sync partner needs to 
> store them

Currently, this is possible using nsIAbMDBCard.getStringAttribute; when 
the nsIAbCard refactoring lands, getProperty will be able to do this.
0
Joshua
1/30/2008 9:46:49 PM
David Ascher schrieb:
> 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).

Another reason why people don't use TB are the missing fields in 
addressbook.

Regards,
Thomas
0
Thomas
1/30/2008 9:46:53 PM
Magnus Melin keyboarded, On 1/30/2008 2:25 PM :
> On 2008-01-30 07:12, Ron K. wrote:
>>
>> 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.
>
> I haven't used the extensions bug it doesn't sound very sensible 
> including "bug fix" extensions like the "No New Windows on Double 
> Click" ext. That issue is was a fixed long time ago in the release 
> builds.

OK, I have disabled that extension to test for potential regressions.  
How about the function provided by 'Unselect Mesage' that stops Tb 
auto-opening next message when current message is moved or deleted.

> For things that are clearly bugs I would encourage extension authors 
> (and others) to provide patches for the bugs instead. Obviously some 
> functionality is not the kind of users in general would want, and such 
> things should remain as extensions.
>
>  -Magnus
>

My take on some bugs is the extensions were done as workarounds and were 
commented as such in the bugs they addressed.  Mnehy is an example that 
dealt with news msg reference numbers among other workarounds.

I agree some functions are not right for integration. Were I see a 
strong win is some of the extensions have a very high overhead to 
payload ratio as a consequence of the *.xpi manifesting bundle and 
redundant tri-licence declarations.

-- 
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!
0
Ron
1/30/2008 9:47:15 PM
ovidiu keyboarded, On 1/30/2008 4:30 PM :
> Ron K. wrote:
>> ovidiu keyboarded, On 1/30/2008 6:08 AM :
>>> Ron K. wrote:
>>>> David Ascher keyboarded, On 1/29/2008 5:49 PM :
>>>>> ovidiu wrote:
>>>>>>> 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
>>>>>
>>>>
>>>> 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.
>>> I have to say that I pointed out documentation as there is none for 
>>> the 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..
>>
>>
>> I have never liked how Tb lacks local offline help.  I see a way to 
>> deal with independent updating between releases.  Since Tb handles 
>> JAR files, the HTML help documents could be archived into a 
>> Help.Jar.  Downside is this would need expansion of the update code 
>> and the Add-on Manager to do the install. The essence of this is a 
>> behavior that is consistent with Add-on and Theme updating.
>> Beyond that I suspect that some code would be needed to support 
>> extracting content from the Help.Jar and steering the content to the 
>> display. I would not want a simple window to be modal. The window 
>> should be minimizable to permit seeing other windows being tutored by 
>> the Help.
>>
> [OK, non modal, just like compose, addons etc..]
>
> Be it that or like an extension, is not for me to say as I don't really
> understand the deep app and how easy or not something is. It is
> important IMHO to have a very easy way of creating and distributing
> help, html mostly, so that extensions may just drop their peace of help
> in the same 'place'. [Is it doable as just for having html and little
> bit of a hook to be understood as 'help'?]
>
> If, say, there would be a window/pane (tab etc.) dedicated to this, it
> may just read more than one 'help', which may just show as folders or
> subfolders etc (just to use structures already defined..) corresponding
> to main help and extensions helps. That may even allow extra help to be
> added from 3rd party dev or may end up in a modular help that can be
> even more independently updated: basic help, getting started, tutorials
> etc.. Think of the TB and lightning ,going together but upgrading at
> different pace and also upgrading help at different pace.
>
> Saying that leads me to an even 'bolder' idea: What if the help
> page/pane/window would just look more or less like a bookmark one,
> having added the corresponding links to various help files, *local and
> web*, course, showing that with something like online/offline mode. In
> this way it can be even more flexible for extension devs or the 3rd
> party... and may even mix various resources.[ Should I dear to say even
> grouping /organizing them etc? What is the relation to FF or other
> browser bookmarks? the ideal AB as in another thread..?.. ]
>
> ok, ok, stop!

Your OK, you have said many of the same things I have thought.  To me 
navigation of Help starts with a Table of Content page holding links to 
all categories.  Then as links are clicked screen content shifts to the 
new selection.  I think the web site is the model to consider as users 
are all ready familiar with it from web browsing.  Adding content would 
only require adding or removing links and HTML files from the Help.Jar. 
An advantage is the Table of Contents and topic pages can also host 
links to external help resources. This can be a resource in addition to 
the links many Add-on developers provide through there Add-on as viewed 
in the Add-on Manager.  For Add-on help, I wonder of many common users 
even know of the links hidden through the Add-on Manager.

I think this is the easiest way.  Trying to use a Tree model similar to 
the Folder Pane would be too expensive in manpower and probably harder 
to update.

-- 
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!
0
Ron
1/30/2008 10:05:15 PM
Ron K. wrote:
> ovidiu keyboarded, On 1/30/2008 4:30 PM :
>> Ron K. wrote:
>>> ovidiu keyboarded, On 1/30/2008 6:08 AM :
>>>> Ron K. wrote:
>>>>> David Ascher keyboarded, On 1/29/2008 5:49 PM :
>>>>>> ovidiu wrote:
>>>>>>>> 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
>>>>>>
>>>>>
>>>>> 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.
>>>> I have to say that I pointed out documentation as there is none for 
>>>> the 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..
>>>
>>>
>>> I have never liked how Tb lacks local offline help.  I see a way to 
>>> deal with independent updating between releases.  Since Tb handles 
>>> JAR files, the HTML help documents could be archived into a 
>>> Help.Jar.  Downside is this would need expansion of the update code 
>>> and the Add-on Manager to do the install. The essence of this is a 
>>> behavior that is consistent with Add-on and Theme updating.
>>> Beyond that I suspect that some code would be needed to support 
>>> extracting content from the Help.Jar and steering the content to the 
>>> display. I would not want a simple window to be modal. The window 
>>> should be minimizable to permit seeing other windows being tutored 
>>> by the Help.
>>>
>> [OK, non modal, just like compose, addons etc..]
>>
>> Be it that or like an extension, is not for me to say as I don't really
>> understand the deep app and how easy or not something is. It is
>> important IMHO to have a very easy way of creating and distributing
>> help, html mostly, so that extensions may just drop their peace of help
>> in the same 'place'. [Is it doable as just for having html and little
>> bit of a hook to be understood as 'help'?]
>>
>> If, say, there would be a window/pane (tab etc.) dedicated to this, it
>> may just read more than one 'help', which may just show as folders or
>> subfolders etc (just to use structures already defined..) corresponding
>> to main help and extensions helps. That may even allow extra help to be
>> added from 3rd party dev or may end up in a modular help that can be
>> even more independently updated: basic help, getting started, tutorials
>> etc.. Think of the TB and lightning ,going together but upgrading at
>> different pace and also upgrading help at different pace.
>>
>> Saying that leads me to an even 'bolder' idea: What if the help
>> page/pane/window would just look more or less like a bookmark one,
>> having added the corresponding links to various help files, *local and
>> web*, course, showing that with something like online/offline mode. In
>> this way it can be even more flexible for extension devs or the 3rd
>> party... and may even mix various resources.[ Should I dear to say even
>> grouping /organizing them etc? What is the relation to FF or other
>> browser bookmarks? the ideal AB as in another thread..?.. ]
>>
>> ok, ok, stop!
>
> Your OK, you have said many of the same things I have thought.  To me 
> navigation of Help starts with a Table of Content page holding links 
> to all categories.  Then as links are clicked screen content shifts to 
> the new selection.  I think the web site is the model to consider as 
> users are all ready familiar with it from web browsing.  Adding 
> content would only require adding or removing links and HTML files 
> from the Help.Jar. An advantage is the Table of Contents and topic 
> pages can also host links to external help resources. This can be a 
> resource in addition to the links many Add-on developers provide 
> through there Add-on as viewed in the Add-on Manager.  For Add-on 
> help, I wonder of many common users even know of the links hidden 
> through the Add-on Manager.
>
> I think this is the easiest way.  Trying to use a Tree model similar 
> to the Folder Pane would be too expensive in manpower and probably 
> harder to update.
>
I think I was refering to the tree as for a list of the available helps: 
Main TB, Lightn, Extension1, ex2, ex3.. But, then again, some sord of 
toc would do. I think I'll add some of this to the wiki above, but 
that's for tomorrow..
0
ovidiu
1/30/2008 10:22:16 PM
> 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.

Not ideal I know, but how about this for an alternative:

Grab yourself a zip/compressed build of SeaMonkey or Firefox, extract 
it, then copy across the extensions\inspector@mozilla.org from SM/FF to TB.

There are no binary components now to the DOMI extension now (they are 
all in gecko), so it should just work.

Standard8
0
Mark
1/30/2008 10:24:45 PM
Joshua Cranmer wrote:
> Norbert P�schel wrote:
>> Synchronisation needs basically 3 things:
> 
> As someone who is working on both the AB rewrite and demorkification for 
> AB (bugs 413260 and 382876, respectively), let me address these points:
> 
>> - a unique UUID per contact
> It is planned to be almost there: we can guarantee a UUID for all cards 
> within the database and a UUID for the database/directory itself. So 
> it's a tupled-UUID; is this sufficient?

Lists and addressbooks need unique identifiers too.
Would be great if there was a uniform mechanism for this - ie "given a 
card/list/addressbook, give me the unique id"

>> - timestamps (last modification time) to detect changes easier
> This already exists (nsIAbCard.lastModifiedDate, er, 
> nsIAbCard.getProperty("LastModifiedDate") :-) ), but it is up to the 
> user of the card to update it last I checked.

Timestamps are inadequate for change detection, here's somes reasons off 
the top of my head (which apply to tb 2.0 not trunk):
- when a card is first created, timestamp is zero
- timestamp gets set to zero when a card is dragged/dropped
   across folders
- the timestamp appears to change even though none of the contact
   fields have changed.  Haven't delved into why - but have
   a feeling this sometimes happens when a card is "used"
- timestamps aren't maintained for addressbooks and lists
- and of course: time isn't guaranteed monotonically increasing

My wish-list for change detection would be:
- a monotically increasing "modification sequence number"
- one for content and one for meta-data
- for each of: contacts, lists and folders

This'd provide a uniform mechanism with clear semantics across all the 
addressbook objects.

>> - a way to store custum data per contact if the sync partner needs to 
>> store them
> 
> Currently, this is possible using nsIAbMDBCard.getStringAttribute; when 
> the nsIAbCard refactoring lands, getProperty will be able to do this.

Is it planned that the custom data (and unique id) will be maintained 
after a drag+drop from one addressbook to another?  Currently they're not.

Not sure if this is the right forum for this discussion - seems a bit 
off topic ... if so perhaps someone could point me to the right place.

Leni.
0
mozilla
1/31/2008 12:33:27 AM
Mark Banner wrote:
>> 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.
>
> Not ideal I know, but how about this for an alternative:
>
> Grab yourself a zip/compressed build of SeaMonkey or Firefox, extract
> it, then copy across the extensions\inspector@mozilla.org from SM/FF to TB.
>
> There are no binary components now to the DOMI extension now (they are
> all in gecko), so it should just work.
>
> Standard8

Thanks Mark, that almost works. I grabbed a current SeaMonkey trunk.
It mostly works except for the Dom window, there I get a blank window and errors like:
Error: null has no properties
Source File: chrome://inspector/content/viewers/dom/dom.js
Line: 87

Joe

0
JoeS
1/31/2008 1:37:48 AM
JoeS keyboarded, On 1/30/2008 8:37 PM :
> Mark Banner wrote:
>>> 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.
>>
>> Not ideal I know, but how about this for an alternative:
>>
>> Grab yourself a zip/compressed build of SeaMonkey or Firefox, extract
>> it, then copy across the extensions\inspector@mozilla.org from SM/FF 
>> to TB.
>>
>> There are no binary components now to the DOMI extension now (they are
>> all in gecko), so it should just work.
>>
>> Standard8
>
> Thanks Mark, that almost works. I grabbed a current SeaMonkey trunk.
> It mostly works except for the Dom window, there I get a blank window 
> and errors like:
> Error: null has no properties
> Source File: chrome://inspector/content/viewers/dom/dom.js
> Line: 87
>
> Joe
>

LOL, null=null, what a hoot.

-- 
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!
0
Ron
1/31/2008 1:57:34 AM
On 1/30/08 1:09 PM, _Ron K._ spoke thusly:
> I have never liked how Tb lacks local offline help.  I see a way to deal 
> with independent updating between releases.  Since Tb handles JAR files, 
> the HTML help documents could be archived into a Help.Jar.  Downside is 
> this would need expansion of the update code and the Add-on Manager to 
> do the install. The essence of this is a behavior that is consistent 
> with Add-on and Theme updating.
> Beyond that I suspect that some code would be needed to support 
> extracting content from the Help.Jar and steering the content to the 
> display. I would not want a simple window to be modal. The window should 
> be minimizable to permit seeing other windows being tutored by the Help.

It's old, but it's worth a look:
<http://interimhelp4tbird.mozdev.org/>

-- 
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
0
Chris
1/31/2008 3:18:07 AM
Ron K. wrote:
> JoeS keyboarded, On 1/30/2008 8:37 PM :
>> Mark Banner wrote:
>>>> 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.
>>>
>>> Not ideal I know, but how about this for an alternative:
>>>
>>> Grab yourself a zip/compressed build of SeaMonkey or Firefox, extract
>>> it, then copy across the extensions\inspector@mozilla.org from SM/FF 
>>> to TB.
>>>
>>> There are no binary components now to the DOMI extension now (they are
>>> all in gecko), so it should just work.
>>>
>>> Standard8
>>
>> Thanks Mark, that almost works. I grabbed a current SeaMonkey trunk.
>> It mostly works except for the Dom window, there I get a blank window 
>> and errors like:
>> Error: null has no properties
>> Source File: chrome://inspector/content/viewers/dom/dom.js
>> Line: 87
>>
>> Joe
>>
> 
> LOL, null=null, what a hoot.
> Hmmm I might have to take that back.
After clicking around repeatedly in File>>inspect a window It seems to be working now.
Not sure what made it start working.

0
JoeS
1/31/2008 5:26:25 AM
JoeS wrote:
> Ron K. wrote:
>> JoeS keyboarded, On 1/30/2008 8:37 PM :
>>> Mark Banner wrote:
>>>>> 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.
>>>>
>>>> Not ideal I know, but how about this for an alternative:
>>>>
>>>> Grab yourself a zip/compressed build of SeaMonkey or Firefox, extract
>>>> it, then copy across the extensions\inspector@mozilla.org from SM/FF
>>>> to TB.
>>>>
>>>> There are no binary components now to the DOMI extension now (they are
>>>> all in gecko), so it should just work.
>>>>
>>>> Standard8
>>>
>>> Thanks Mark, that almost works. I grabbed a current SeaMonkey trunk.
>>> It mostly works except for the Dom window, there I get a blank window
>>> and errors like:
>>> Error: null has no properties
>>> Source File: chrome://inspector/content/viewers/dom/dom.js
>>> Line: 87
>>>
>>> Joe
>>>
>>
>> LOL, null=null, what a hoot.
>> Hmmm I might have to take that back.
> After clicking around repeatedly in File>>inspect a window It seems to
> be working now.
> Not sure what made it start working.
>
Ooops. It must be time to go to bed. I was bouncing between branch and trunk builds, and tried in the wrong build.
It definitely does *Not* work in trunk.


0
JoeS
1/31/2008 5:38:31 AM
Joshua Cranmer schrieb:
> Norbert P�schel wrote:
>> Synchronisation needs basically 3 things:
> 
> As someone who is working on both the AB rewrite and demorkification for 
> AB (bugs 413260 and 382876, respectively), let me address these points:
> 
>> - a unique UUID per contact
> It is planned to be almost there: we can guarantee a UUID for all cards 
> within the database and a UUID for the database/directory itself. So 
> it's a tupled-UUID; is this sufficient?
> 

That would be perfect - I can always just concatenate them for the 
export to another application.

>> - timestamps (last modification time) to detect changes easier
> 
> This already exists (nsIAbCard.lastModifiedDate, er, 
> nsIAbCard.getProperty("LastModifiedDate") :-) ), but it is up to the 
> user of the card to update it last I checked.
> 

Which makes it pretty useless for synchronisation... automatic updates 
would be better.

>> - a way to store custum data per contact if the sync partner needs to 
>> store them
> 
> Currently, this is possible using nsIAbMDBCard.getStringAttribute; when 
> the nsIAbCard refactoring lands, getProperty will be able to do this.

Good. In the long term, the UI should be made flexible enough that the 
user can access such properties as custum data fields.

Norbert
0
ISO
1/31/2008 8:01:08 AM
Thomas wrote on 30. Jan 2008

>> 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).
> 
> Another reason why people don't use TB are the missing fields in 
> addressbook.

I seriously doubt that this is a serious showstopper all by itself
It's annoying for sure, but I find it hard to believe that someon
would not use Thunderbird just because of this

Simo

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
0
Simon
1/31/2008 12:35:36 PM
Thomas wrote:
> Another reason why people don't use TB are the missing fields in 
> addressbook.

It is not a big deal for me... The main trouble with the address book is 
the lack of serious synchro with cell phones, smartphones or PDAs (yes, 
there is something e.g. for Palm (see 
http://kb.mozillazine.org/PalmSync_(Thunderbird)#Issues_and_Limitations), 
but with too much issues and limitations).

Maybe it is different in the US, but in Europe most power users (= 
typical TB target market) rely on their smartphone as main address book, 
hence a smooth integration is a must.

Of course, the same applies to the calendar data...

Pascal
0
Pascal
1/31/2008 2:10:24 PM
Gervase Markham wrote:
> 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)

Why mention IMAP when talking about offline mail?

Another reason we should push for using Thunderbird is privacy. David 
has written about this already:

http://ascher.ca/blog/2007/12/11/privacy-the-new-global-warming/

And perhaps trying to compete with webmail is a bit of a misnomer. Each 
has their own merits, and after all, Thunderbird can be set up to be a 
great front end for GMail (and other webmail services):

http://lifehacker.com/software/geek-to-live/turn-thunderbird-into-the-ultimate-gmail-imap-client-314574.php

- Brian
0
Brian
1/31/2008 3:12:55 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pascal Sartoretti wrote:
> Thomas wrote:
>> Another reason why people don't use TB are the missing fields in 
>> addressbook.
> 
> It is not a big deal for me... The main trouble with the address book is 
> the lack of serious synchro with cell phones, smartphones or PDAs (yes, 
> there is something e.g. for Palm (see 
> http://kb.mozillazine.org/PalmSync_(Thunderbird)#Issues_and_Limitations), 
> but with too much issues and limitations).
> 
> Maybe it is different in the US, but in Europe most power users (= 
> typical TB target market) rely on their smartphone as main address book, 
> hence a smooth integration is a must.
> 
> Of course, the same applies to the calendar data...
> 

I was going to bring this one up, but as a veteran of <24hrs on the
list, I didn't want to be the first.

If Thunderbird can conform to iCal, WebDav and CalDav standards (where
appropriate) and get SyncML synchronization working then it'd be a
massive bonus.

I'm coming from a server-supplier angle, where we've gone with the horde
web mail framework (where users can use webmail).  I hate MS Outlook as
it has crippled IMAP support, yet users still use it to synchronize with
their palms, WinCE mobiles and Blackberries.

I'd love to be able to offer Thunderbird as an off line client (I use it
myself for mail) and the ability for contacts, and calendar
synchronization I think would be a massive leap forwards.  (as a
standard feature of TB - I know little about add-ons that have this
functionality).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHoghmauMjEM4rxIQRAk4oAJkBI8SQv0f4YaasmSH1QgCzTcnVkwCfXwc4
Qj+Zn0CNZrBz2duG9vVPWi4=
=f7t3
-----END PGP SIGNATURE-----
0
andy
1/31/2008 5:41:58 PM
mozilla.org@zindus.com wrote:
>> It is planned to be almost there: we can guarantee a UUID for all
>> cards within the database and a UUID for the database/directory
>> itself. So it's a tupled-UUID; is this sufficient?
>
> Lists and addressbooks need unique identifiers too.
> Would be great if there was a uniform mechanism for this - ie "given a
> card/list/addressbook, give me the unique id"

Yes it will be on cards, groups and address books. The format is 
undetermined at the moment, hopefully I'll have some ideas in a few days.

>>> - timestamps (last modification time) to detect changes easier
>> This already exists (nsIAbCard.lastModifiedDate, er,
>> nsIAbCard.getProperty("LastModifiedDate") :-) ), but it is up to the
>> user of the card to update it last I checked.
>
> Timestamps are inadequate for change detection, here's somes reasons off
> the top of my head (which apply to tb 2.0 not trunk):
> - when a card is first created, timestamp is zero
> - timestamp gets set to zero when a card is dragged/dropped
> across folders
> - the timestamp appears to change even though none of the contact
> fields have changed. Haven't delved into why - but have
> a feeling this sometimes happens when a card is "used"
> - timestamps aren't maintained for addressbooks and lists
> - and of course: time isn't guaranteed monotonically increasing

Actually, most of this sounds like bugs in the way we handle timestamps, 
most of which is most likely because we don't really use them for 
anything at the moment. The last point is good though.

> Not sure if this is the right forum for this discussion - seems a bit
> off topic ... if so perhaps someone could point me to the right place.

This newsgroup is the right forum, though we probably need to branch 
this into a separate thread. Give me a few more days and hopefully I'll 
have something more that will form a good basis for a discussion on the 
address book interfaces etc.

Standard8
0
Mark
1/31/2008 7:17:29 PM
Simon Paquet schrieb:
>> Another reason why people don't use TB are the missing fields in 
>> addressbook.
> 
> I seriously doubt that this is a serious showstopper all by itself.
> It's annoying for sure, but I find it hard to believe that someone
> would not use Thunderbird just because of this.

hmm, I am "someone" who won't use TB for mail because of missing fields 
in addressbook. :-(

Until yet I am using Outlook 2000, but I am looking for an alternative, 
which handles also my calender and contacts. Because of the contacts I 
won't move to TB. The calender-functionality of Lightning is great, if 
also birthdays will be handled by TB and Lightning.

Thomas
0
Thomas
1/31/2008 10:05:04 PM


---On 2008.Jan.29 08:44 AM, Peter Lairo wrote:
> Pascal Sartoretti on 29.01.2008 09:57 wrote:
>> David Ascher wrote:
>>> * Release-defining features:
>>
>> I would add RSS to this list 
>
> I disagree that RSS is important to Thunderbird. 

personally, i would strongly disagree with this.  i wouldn't use Tb for 
just mail, but use it because of mail + rss +...  and it seems this 
issue of 'bloat' is one we can't get past.  the solution is incredibly 
simple: at install time ask the user which particular Account Categories 
(Protocols) are to be installed, in the same way DOM Inpector was/is 
done.  it should be absolutely possible for a non-rss user to not load 
it; it is absolutely required that Tb expands beyond a 'return to pine' 
to be successful.

of course this requires some smart architecture centered on Account 
Manager; it seems like some people are looking at this fortunately.

btw JoeS, yes when there's a DOMi that works with Tb trunk, i'll update 
morelayouts..
0
alta88
1/31/2008 10:31:48 PM
Thomas keyboarded, On 1/30/2008 4:46 PM :
> David Ascher schrieb:
>> 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).
>
> Another reason why people don't use TB are the missing fields in 
> addressbook.
>
> Regards,
> Thomas

You seem not to know about the extension "MoreFunctionsForAddressbook" 
that makes use of several of the reserved data field ID's that were 
provided in the design for future customization. Look here: 
http://nic-nac-project.de/~kaosmos/index-en.html

-- 
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!
0
Ron
1/31/2008 10:46:24 PM
andy keyboarded, On 1/31/2008 12:41 PM :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Pascal Sartoretti wrote:
>   
>> Thomas wrote:
>>     
>>> Another reason why people don't use TB are the missing fields in 
>>> addressbook.
>>>       
>> It is not a big deal for me... The main trouble with the address book is 
>> the lack of serious synchro with cell phones, smartphones or PDAs (yes, 
>> there is something e.g. for Palm (see 
>> http://kb.mozillazine.org/PalmSync_(Thunderbird)#Issues_and_Limitations), 
>> but with too much issues and limitations).
>>
>> Maybe it is different in the US, but in Europe most power users (= 
>> typical TB target market) rely on their smartphone as main address book, 
>> hence a smooth integration is a must.
>>
>> Of course, the same applies to the calendar data...
>>
>>     
>
> I was going to bring this one up, but as a veteran of <24hrs on the
> list, I didn't want to be the first.
>
> If Thunderbird can conform to iCal, WebDav and CalDav standards (where
> appropriate) and get SyncML synchronization working then it'd be a
> massive bonus.
>
> I'm coming from a server-supplier angle, where we've gone with the horde
> web mail framework (where users can use webmail).  I hate MS Outlook as
> it has crippled IMAP support, yet users still use it to synchronize with
> their palms, WinCE mobiles and Blackberries.
>
> I'd love to be able to offer Thunderbird as an off line client (I use it
> myself for mail) and the ability for contacts, and calendar
> synchronization I think would be a massive leap forwards.  (as a
> standard feature of TB - I know little about add-ons that have this
> functionality).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHoghmauMjEM4rxIQRAk4oAJkBI8SQv0f4YaasmSH1QgCzTcnVkwCfXwc4
> Qj+Zn0CNZrBz2duG9vVPWi4=
> =f7t3
> -----END PGP SIGNATURE-----
>   

Lightning is the Calendar extension for Tunderbird and supports iCal and 
WebCal as I understand.
See this Wiki: http://wiki.mozilla.org/Calendar:Home_Page
A road map link is available.

-- 
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!
0
Ron
1/31/2008 10:53:06 PM
alta88 keyboarded, On 1/31/2008 5:31 PM :
>
>
>
> ---On 2008.Jan.29 08:44 AM, Peter Lairo wrote:
>> Pascal Sartoretti on 29.01.2008 09:57 wrote:
>>> David Ascher wrote:
>>>> * Release-defining features:
>>>
>>> I would add RSS to this list 
>>
>> I disagree that RSS is important to Thunderbird. 
>
> personally, i would strongly disagree with this.  i wouldn't use Tb 
> for just mail, but use it because of mail + rss +...  and it seems 
> this issue of 'bloat' is one we can't get past.  the solution is 
> incredibly simple: at install time ask the user which particular 
> Account Categories (Protocols) are to be installed, in the same way 
> DOM Inpector was/is done.  it should be absolutely possible for a 
> non-rss user to not load it; it is absolutely required that Tb expands 
> beyond a 'return to pine' to be successful.
>
> of course this requires some smart architecture centered on Account 
> Manager; it seems like some people are looking at this fortunately.
>
> btw JoeS, yes when there's a DOMi that works with Tb trunk, i'll 
> update morelayouts..

I add my support to the install time concept of selecting supplemental 
protocols.  The DOMi and Talkback model is a good one from my view 
point.  What may Windows installers offer are options to do a "Repair" 
install so items previously skipped can be added, or selected items 
removed.  For Tb, I think an easy way to add protocol modules in a 
"Repair" action should be considered. 

FWIW, I do RSS in Fx because I have a strong dislike for the Tb 
implementation. To me the RSS should list the servers in the RSS folder 
and then use the Thread Pane to display the available topics in the same 
method news list headers. To Me Folder Pane space is too valuable to be 
waisted in the manner I observed when I evaluated the feature two years ago.

-- 
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!
0
Ron
1/31/2008 11:59:38 PM
Sorry for the delay, it's been a crazy couple of days.  It'll take me a 
few days to read all of the posts carefully.

A few high-level points:

On RSS: I agree, there may be some great gains to be had in improving 
the RSS capabilities, and as far as I know there are no scary elephants 
in the room from a technology point of view.

On Exchange interop: others have already pointed out some of the issues 
(licensing and otherwise) in building full Exchange support into the 
core product.  I'd love to see an extension tackle this, however, I 
think it would be very popular.  As I've written elsewhere, I do think 
we should do a better job of interop with Outlook users, such as 
tackling some of the winmail.dat issues.

On impact on Calendar dev & test practices: that's a long conversation, 
which I'm hoping to start next week when I meet Daniel and Christian in 
person finally.  We'll of course report on what we discuss.

On synchronization: synchronization with devices is a very important 
issue for many users, but it also feels currently like a huge mountain 
of interoperability problems, with no good clean solution yet.  I'm 
hoping to learn more about the various open source synchronization 
libraries, and this is an area where if there are motivated 
contributors, progress could happen faster.

On auto-configuration and data migration: absolutely, there's lots of 
great gains to be had there, and we'll start with the easier ones.

On a lot of the other comments: I'm sure everyone can understand the #1 
challenge for Thunderbird product management: for every user, there is a 
different list of must-have features or bugs.  Satisfying everyone won't 
be possible.

More later!

--david

0
David
2/1/2008 1:38:23 AM
Axel Hecht wrote:
> The other suggestion in the corresponding bug is to create a separate
> mimetype for each app supported by AMO

Since AMO's files are mirrored, that means that the increasing number of 
extensions that work in three, four, five, or more Toolkit-based apps 
would need to have three, four, five or more different files, and would 
still need some magic for dispatch from the one big shiny "Install Now" 
button in the AMO web page, probably the browsers' install dialogs 
knowing about every Toolkit app installed, and asking "did you want to 
install that thing you just clicked on in just the browser where you 
are, or also in Thunderbird, or I see you have Sunbird and Songbird 
installed, how about there?" Not sure about the current AMO and EM 
owners, but last time I talked about that situation, everyone got a lot 
less excited about mimetypes as a solution.

Phil Ringnalda
0
Phil
2/1/2008 5:26:21 AM
Phil Ringnalda keyboarded, On 2/1/2008 12:26 AM :
> Axel Hecht wrote:
>> The other suggestion in the corresponding bug is to create a separate
>> mimetype for each app supported by AMO
>
> Since AMO's files are mirrored, that means that the increasing number 
> of extensions that work in three, four, five, or more Toolkit-based 
> apps would need to have three, four, five or more different files, and 
> would still need some magic for dispatch from the one big shiny 
> "Install Now" button in the AMO web page, probably the browsers' 
> install dialogs knowing about every Toolkit app installed, and asking 
> "did you want to install that thing you just clicked on in just the 
> browser where you are, or also in Thunderbird, or I see you have 
> Sunbird and Songbird installed, how about there?" Not sure about the 
> current AMO and EM owners, but last time I talked about that 
> situation, everyone got a lot less excited about mimetypes as a solution.
>
> Phil Ringnalda

Yes the Fx download manger would need to be smarter.  Multiple copies of 
add-on files at AMO are not needed if each link served uses a custom 
MIME for the product the user needs the Add-on for.  In the discussion 
of http://wiki.mozilla.org/Thunderbird:Extension_Installation
I suggested application/x-xpi-... with an extension indicating the 
product targeted.  Then the browser would install if it were an Fx xpi 
and activate the file save dialog if a Tb or other local install product 
were the target. The MIME types would then be pre-configured into the 
File Types dialog.

Otherwise, the pages for Tb Add-on's will need a separate page template 
with a Download button in place of the Fx Install button.  The MIME 
alternative means a page can have a Fx link that does the auto-install 
and Tb links that auto-save.

As long as *.xpi is a common file extension for different products with 
different install methods we will have User confusion. Server side MIME 
cueing offers time for a more elegant solution.

-- 
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!
0
Ron
2/1/2008 6:22:34 AM
Ron K. wrote:
> Multiple copies of
> add-on files at AMO are not needed if each link served uses a custom
> MIME for the product the user needs the Add-on for.

Mmm, no. They are _mirrored_. When you request 
http://releases.mozilla.org/pub/mozilla.org/addons/4444/whateveritis.xpi, you 
are actually getting the file from one of several dozen mirrors, maybe 
http://mozilla.cs.utah.edu/pub/mozilla.org/addons/ or 
http://www.wsection.com/mozilla/addons/ or wherever. The mirrors don't, 
and won't, run a script that will vary content-type based on the 
request. So to vary the content type, AMO would either need to increase 
the storage requirements for mirrors (double? dunno), or would need to 
not use the mirrors, increasing their required bandwidth by several 
dozen times.

Phil Ringnalda
0
Phil
2/1/2008 6:39:08 AM
Phil Ringnalda keyboarded, On 2/1/2008 1:39 AM :
> Ron K. wrote:
>> Multiple copies of
>> add-on files at AMO are not needed if each link served uses a custom
>> MIME for the product the user needs the Add-on for.
>
> Mmm, no. They are _mirrored_. When you request 
> http://releases.mozilla.org/pub/mozilla.org/addons/4444/whateveritis.xpi, 
> you are actually getting the file from one of several dozen mirrors, 
> maybe http://mozilla.cs.utah.edu/pub/mozilla.org/addons/ or 
> http://www.wsection.com/mozilla/addons/ or wherever. The mirrors 
> don't, and won't, run a script that will vary content-type based on 
> the request. So to vary the content type, AMO would either need to 
> increase the storage requirements for mirrors (double? dunno), or 
> would need to not use the mirrors, increasing their required bandwidth 
> by several dozen times.
>
> Phil Ringnalda

So if I follow this right, AMO hosts the Add-on descriptions with a 
link.  Then the file request from the on-click redirects to an available 
mirror to execute an FTP or HTTP transfer. That there is only one 
whateveritis.xpi and we keep them straight through AMO pages being 
sorted as accessed from the Tb or Fx sidebar buttons. Oh that it would 
be as simple as a MIME type in the on-click link.  I see why you made 
the multiple file copy comment.  That also gives reason for rejection of 
multiple revisions of the *.xpi one person suggested where an f,m,s,or t 
be appended to *.xpi.

Now I see why You were sketching a design for a highly intelligent 
module on the Fx side that would be Mozilla family aware. So when I have 
Fx and Tb it would use that to prompt me for a processing choice.

-- 
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!
0
Ron
2/1/2008 7:19:21 AM
Ron K. wrote:
> Phil Ringnalda keyboarded, On 2/1/2008 1:39 AM :
>> Ron K. wrote:
>>> Multiple copies of
>>> add-on files at AMO are not needed if each link served uses a custom
>>> MIME for the product the user needs the Add-on for.
>>
>> Mmm, no. They are _mirrored_. When you request 
>> http://releases.mozilla.org/pub/mozilla.org/addons/4444/whateveritis.xpi, 
>> you are actually getting the file from one of several dozen mirrors, 
>> maybe http://mozilla.cs.utah.edu/pub/mozilla.org/addons/ or 
>> http://www.wsection.com/mozilla/addons/ or wherever. The mirrors 
>> don't, and won't, run a script that will vary content-type based on 
>> the request. So to vary the content type, AMO would either need to 
>> increase the storage requirements for mirrors (double? dunno), or 
>> would need to not use the mirrors, increasing their required 
>> bandwidth by several dozen times.
>>
>> Phil Ringnalda
>
> So if I follow this right, AMO hosts the Add-on descriptions with a 
> link.  Then the file request from the on-click redirects to an 
> available mirror to execute an FTP or HTTP transfer. That there is 
> only one whateveritis.xpi and we keep them straight through AMO pages 
> being sorted as accessed from the Tb or Fx sidebar buttons. Oh that it 
> would be as simple as a MIME type in the on-click link.  I see why you 
> made the multiple file copy comment.  That also gives reason for 
> rejection of multiple revisions of the *.xpi one person suggested 
> where an f,m,s,or t be appended to *.xpi.
>
> Now I see why You were sketching a design for a highly intelligent 
> module on the Fx side that would be Mozilla family aware. So when I 
> have Fx and Tb it would use that to prompt me for a processing choice.
>
If that is to be a smart solution in Fx, you also have to consider that 
with other browsers things may still be the same. Ok, is very likely for 
one to use FF with TB, but what if not? Or what if seamonkey? Or other..
While multiple copies and 3-4 xpi per extension (for the sake of xpif, 
xpit, xpis etc) may raise other isssues, including the simple fact that 
the AMO to be reorganized by going trough all the content there, still, 
having separate mimetypes, seams the safest or most simple one from a 
user pov. Cause it allows not only to have simple web installation with 
one click, but also dld (or get by mail from someone) and double click..
And also, I think this is not only about AMO as that is not the only 
source of xpi. There are others or may even be the case for inhouse 
extensions.. (https://nic-nac-project.de/~kaosmos/index-en.html , 
http://milimail.org/milimail/index.php/Main_Page or 
http://admisource.gouv.fr/frs/?group_id=40 and others..)

hmm.., or maybe I don't get the essential idea here...
0
ovidiu
2/1/2008 8:46:03 AM
Mark Banner wrote:
>> 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.
>>     
>
> Not ideal I know, but how about this for an alternative:
>
> Grab yourself a zip/compressed build of SeaMonkey or Firefox, extract 
> it, then copy across the extensions\inspector@mozilla.org from SM/FF to TB.
>
> There are no binary components now to the DOMI extension now (they are 
> all in gecko), so it should just work.
>
> Standard8
>   
I tried that once. The resulting DOMi was totally broken. I could have
been doing something wrong though.

Phil
0
Philip
2/1/2008 3:53:49 PM
Brian King wrote:
> Why mention IMAP when talking about offline mail?

Because it seems to me that if you want to access your email both 
offline and also via the web, IMAP is the only game in town. OK, perhaps 
you can do POP with leave-on-server, but I always though that had 
problems (e.g. no folders). BICBW.

> And perhaps trying to compete with webmail is a bit of a misnomer. Each 
> has their own merits, and after all, Thunderbird can be set up to be a 
> great front end for GMail (and other webmail services):
> 
> http://lifehacker.com/software/geek-to-live/turn-thunderbird-into-the-ultimate-gmail-imap-client-314574.php 

Quite so. We want to get to a position where people use Thunderbird on 
their main computer and webmail when out and about.

Gerv
0
Gervase
2/1/2008 5:38:16 PM
Ron K. schrieb:
> You seem not to know about the extension "MoreFunctionsForAddressbook" 
> that makes use of several of the reserved data field ID's that were 
> provided in the design for future customization. Look here: 
> http://nic-nac-project.de/~kaosmos/index-en.html

I know the extension, but it's one thing to show hidden fields and 
another thing to get the full functionality for the fields, for example: 
I can add the birthday (in separated fields) but there is no event added 
  in lightning! A good addressbook should have those fields in core, and 
not added by an extension.

0
Thomas
2/1/2008 7:33:23 PM
Gervase Markham keyboarded, On 2/1/2008 12:38 PM :
> Brian King wrote:
>> Why mention IMAP when talking about offline mail?
>
> Because it seems to me that if you want to access your email both 
> offline and also via the web, IMAP is the only game in town. OK, 
> perhaps you can do POP with leave-on-server, but I always though that 
> had problems (e.g. no folders). BICBW.

I think your right that POP3 is an INBOX only server side case.  I think 
it is excellent for people like myself with simple domestic mail traffic.

>> And perhaps trying to compete with webmail is a bit of a misnomer. 
>> Each has their own merits, and after all, Thunderbird can be set up 
>> to be a great front end for GMail (and other webmail services):
>>
>> http://lifehacker.com/software/geek-to-live/turn-thunderbird-into-the-ultimate-gmail-imap-client-314574.php 
>
>
> Quite so. We want to get to a position where people use Thunderbird on 
> their main computer and webmail when out and about.
>
> Gerv

I remember the early web mail period when it was universaly viewed as a 
"Roaming" solution.  I still believe that two tier plan is the most 
efficient use of internet mail resources. My experience is I save lots 
of minutes with Tb and POP3 versus my ISP Webmail interface. I see that 
savings as a selling point.

-- 
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!
0
Ron
2/1/2008 9:33:42 PM
Thomas keyboarded, On 2/1/2008 2:33 PM :
> Ron K. schrieb:
>> You seem not to know about the extension 
>> "MoreFunctionsForAddressbook" that makes use of several of the 
>> reserved data field ID's that were provided in the design for future 
>> customization. Look here: 
>> http://nic-nac-project.de/~kaosmos/index-en.html
>
> I know the extension, but it's one thing to show hidden fields and 
> another thing to get the full functionality for the fields, for 
> example: I can add the birthday (in separated fields) but there is no 
> event added  in lightning! A good addressbook should have those fields 
> in core, and not added by an extension.
>

Yes, I understand the point that a manually viewable birthday field is 
not as useful as an integrated field that auto-fills a Lightning event.  
I interpreted your prior remark as lamenting no way to have the birthday 
field. I chose to add and keep the extension with hope that it grows to 
fill some of the gaps in the out-of-box factory Abook. 

-- 
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!
0
Ron
2/1/2008 9:45:30 PM
Thomas wrote:
> Ron K. schrieb:
>> You seem not to know about the extension 
>> "MoreFunctionsForAddressbook" that makes use of several of the 
>> reserved data field ID's that were provided in the design for future 
>> customization. Look here: 
>> http://nic-nac-project.de/~kaosmos/index-en.html
>
> I know the extension, but it's one thing to show hidden fields and 
> another thing to get the full functionality for the fields, for 
> example: I can add the birthday (in separated fields) but there is no 
> event added  in lightning! A good addressbook should have those fields 
> in core, and not added by an extension.
>
there's another extension to add those in LT
0
ovidiu
2/2/2008 11:17:21 AM
>> Ron K. wrote:
>> You seem not to know about the extension
>> "MoreFunctionsForAddressbook" that makes use of several of the
>> reserved data field ID's that were provided in the design for
>> future customization.

Thomas wrote:
> I know the extension, but it's one thing to show hidden fields
> and another thing to get the full functionality for the fields,
> for example: I can add the birthday (in separated fields) but
> there is no event added in lightning!

The extension ThunderBirthDay shows them in Lightning calendar:
<https://addons.mozilla.org/thunderbird/addon/5337>
0
Stefan
2/2/2008 12:56:44 PM
David Ascher wrote:
> On a lot of the other comments: I'm sure everyone can understand the #1
> challenge for Thunderbird product management: for every user, there is a
> different list of must-have features or bugs. Satisfying everyone won't
> be possible.

Welcome to the beauty of community project management ;-)

If it helps, I  can ensure you that it's the same for other projects as 
well (e.g. SeaMonkey) - and usually the people easiest to satisfy are 
those who put their code where their mouth is, those who don't or can't 
are much harder to satisfy with volunteer devs only :)

Robert Kaiser
0
Robert
2/3/2008 3:21:01 PM
Ron K. wrote:
> Yes the Fx download manger would need to be smarter. Multiple copies of
> add-on files at AMO are not needed if each link served uses a custom
> MIME for the product the user needs the Add-on for. In the discussion of
> http://wiki.mozilla.org/Thunderbird:Extension_Installation
> I suggested application/x-xpi-... with an extension indicating the
> product targeted.

And how would you handle the supported and otherwise well-working 
"toolkit" target that makes extensions work with any app based on the 
Mozilla toolkit?

Even though AMO does not explicitely support that currently, there are 
extensions out there that do and even if AMO is the main add-ons 
repository for 4 Mozilla-hosted apps, it's by far not the only source of 
add-ons for Mozilla apps out there.

Robert Kaiser
0
Robert
2/3/2008 3:56:42 PM
Robert Kaiser said on 3.2.2008 16:21:
> David Ascher wrote:
>> On a lot of the other comments: I'm sure everyone can understand the #1
>> challenge for Thunderbird product management: for every user, there is a
>> different list of must-have features or bugs. Satisfying everyone won't
>> be possible.
>
> Welcome to the beauty of community project management ;-)
>
> If it helps, I can ensure you that it's the same for other projects as
> well (e.g. SeaMonkey) - and usually the people easiest to satisfy are
> those who put their code where their mouth is,

Aren't these people actually satisfying *themselves* ? Wouldn't these 
people (who only fix their "scratch" and leave) then cause *zero* effort 
to the regular devs?

> those who don't or can't
> are much harder to satisfy with volunteer devs only :)

Well, yeah! Isn't anything more than *zero* effort "much" harder? :-P

(just messin' with you)
-- 
Regards,

Peter Lairo

The browser you can trust:  www.GetFirefox.com
Reclaim Your Inbox:         www.GetThunderbird.com

Israel - Myths & Facts:     http://www.JewishVirtualLibrary.org/
Dangers of Islam (German):  http://www.pi-news.net/
Church of the Flying Spaghetti Monster:  http://www.venganza.org/
0
Peter
2/4/2008 12:57:50 AM
Robert Kaiser keyboarded, On 2/3/2008 10:56 AM :
> Ron K. wrote:
>> Yes the Fx download manger would need to be smarter. Multiple copies of
>> add-on files at AMO are not needed if each link served uses a custom
>> MIME for the product the user needs the Add-on for. In the discussion of
>> http://wiki.mozilla.org/Thunderbird:Extension_Installation
>> I suggested application/x-xpi-... with an extension indicating the
>> product targeted.
>
> And how would you handle the supported and otherwise well-working 
> "toolkit" target that makes extensions work with any app based on the 
> Mozilla toolkit?
>
> Even though AMO does not explicitely support that currently, there are 
> extensions out there that do and even if AMO is the main add-ons 
> repository for 4 Mozilla-hosted apps, it's by far not the only source 
> of add-ons for Mozilla apps out there.
>
> Robert Kaiser

Robert, Scott was brainstorming and that was my quick and dirty reply. 
Your a code monkey, so i bet you really understand "Toolkit",me as a 
user "toolkit" is a metaphor for  what ???

Here is my bottom line, cause me no grief at the end of the month when 
the bii;;s are due.

-- 
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!
0
Ron
2/4/2008 4:04:14 AM
Peter Lairo wrote:
> Robert Kaiser said on 3.2.2008 16:21:
>> If it helps, I can ensure you that it's the same for other projects as
>> well (e.g. SeaMonkey) - and usually the people easiest to satisfy are
>> those who put their code where their mouth is,
>
> Aren't these people actually satisfying *themselves* ? Wouldn't these
> people (who only fix their "scratch" and leave) then cause *zero* effort
> to the regular devs?

1) Yes, they saisfy themeselves primarily, that's why it's easiest.
2) They don't just scratch their itch and leave most of the time - 
actually, the "regular" developer team of volunteer community projects 
like e.g. SeaMonkey (and currently also Thunderbird) usually consists 
mainly of such people.
3) They don't cause zero effort, as their patches still need to be 
reviewed (often including discussions on the approach, etc.) and checked in.

Robert Kaiser
0
Robert
2/4/2008 4:52:37 PM
Stefan Sitter schrieb:

> The extension ThunderBirthDay shows them in Lightning calendar:
> <https://addons.mozilla.org/thunderbird/addon/5337>

thanks for the info. That all may be only a workaround. What will hapen 
when the fields are working in core TB and create direct an event in TB? 
   The birthday-field was an example. There should also be more phone 
and mailfields, categories and an integration of contacts in events.

What I don't realy understand is, why are extensions developed for those 
functions and not developed in core TB. Don't misunderstand me (sorry, I 
am not so fluent in english), it is good that people develop extensions, 
but on the other side there are bugs in bugzilla tracked, which are 
waiting for a confirmation to go into core TB and add for example the 
birhtdayfield in TB with integration of lightning. Isn't it better to 
develop together on bugzilla?


0
Thomas
2/4/2008 7:31:45 PM
Thomas wrote:
> Stefan Sitter schrieb:
>
>   
>> The extension ThunderBirthDay shows them in Lightning calendar:
>> <https://addons.mozilla.org/thunderbird/addon/5337>
>>     
>
> thanks for the info. That all may be only a workaround. What will hapen 
> when the fields are working in core TB and create direct an event in TB? 
>    The birthday-field was an example. There should also be more phone 
> and mailfields, categories and an integration of contacts in events.
>
> What I don't realy understand is, why are extensions developed for those 
> functions and not developed in core TB. Don't misunderstand me (sorry, I 
> am not so fluent in english), it is good that people develop extensions, 
> but on the other side there are bugs in bugzilla tracked, which are 
> waiting for a confirmation to go into core TB and add for example the 
> birhtdayfield in TB with integration of lightning. Isn't it better to 
> develop together on bugzilla?
>
>   
Right.  One of the things I hope we'll be able to tackle soonish is to 
review the Thunderbird extensions and look for things which probably 
make sense as part of the core product. 

--david ascher

0
David
2/4/2008 8:15:19 PM

Peter Lairo wrote:
> Aren't these people actually satisfying *themselves* ? Wouldn't these
> people (who only fix their "scratch" and leave) then cause *zero* effort
> to the regular devs?

I started fixing some itches in filters if I remember correctly. Since 
then I've been fixing other itches in address book ever since and 
there's still many more to fix ;-)

Standard8
0
Mark
2/4/2008 9:47:26 PM
Gervase Markham wrote:
> 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?
>   

Yes.  In general IMAP is the better protocol, and I think we should 
promote its use (obviously not to the detriment of people who only have 
POP access).

As to the general value proposition of Tb over webmail, I think that you 
hit on a few of them.  In general, there are things that Tb can do that 
most webmail systems can't, like aggregate email accounts, aggregate 
non-email protocols, and be more customizable. There are other things 
that Tb should (and, hopefully, will) do, like provide richer and faster 
interactions.

--david

0
David
2/4/2008 10:53:14 PM
David Ascher wrote:
>
> Yes.  In general IMAP is the better protocol, and I think we should 
> promote its use (obviously not to the detriment of people who only have 
> POP access).
>   
Or perhaps IMAP will help us provider better solutions with TB for the 
enterprise sector. I think this is a direction we want to go at some 
stage...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
2/4/2008 11:56:54 PM
David Ascher wrote:
> Right.  One of the things I hope we'll be able to tackle soonish is to 
> review the Thunderbird extensions and look for things which probably 
> make sense as part of the core product.

How I see it:

- Extensions that modify the data structure (e.g. adding extra fields) 
should rather be in the core product.
- Extensions that modify the behaviour (e.g. display your contacts in a 
3D browser...) can be out of the core.

Hence, the "birthday" field of the address book should be in the core 
product; whereas the functionality of automatically send a birthday 
e-mail should (thankfully) remain in an extension.
0
Pascal
2/5/2008 10:25:01 AM
David Ascher schrieb:
> Andreas Tscharner wrote:
>> 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

Hi David

Regarding Priorities to attract new users: Beside many other valid 
points, keep the following in mind. In order to send an e-mail, one 
needs an e-mail address. In order to NOT having to maintain several 
sources, all have to come from the address book.
Especially with the integration of the calendar function, TB really 
needs a strong and solid address book.

On synchronization: Finally having the ONE solid AddressBook is good, 
but one then wants to have it available everywhere. Hence syncing is 
very important.
Example: As for myself, I carry along about 1'800 addresses on my Palm 
and sync it (still with Outlook due to poor TB AB).

Regarding sync solutions: The project I followed for a while, and to me 
it looks as the most promising one to fulfill the demand of TB (OSS, 
multiplatform capable, flexible, syncing almost everything with 
anything) is / is going to be OpenSync.org  http://www.opensync.org/



Looking forward to this. After using FF for years, I am eagerly waiting 
to be able to get read of M$ Outlook and sync with my PDA/Smartphone/and 
alike.

Regards,
Rolf
0
Rolf
2/6/2008 10:31:44 PM
On Jan 28, 4:53=A0pm, David Ascher <david.asc...@gmail.com> wrote:
> =A0- Significant headway on getting rid of Mork and RDF
> =A0- A concerted effort to improving the extensions ecosystem for
> Thunderbird, including refactorings, FUEL, developer documentation, and
> user experience
David -

Does this refactoring include any changes to the TB chrome structure?
I just say it  because... well TB3 doesn't have a good working DOMi to
go with it right now, so finding anything basically requires that you
dig through MXR. If, for instance, you want to add a toolbarbutton,
there's like 4 files in messenger/content/ that could possibly contain
the toolbox (and that's ignoring a few):

messenger.xul
customizeToolbar.xul
mailOverlay.xul
mailWindowOverlay.xul ** DING DING, That's where toolbarbuttons go.

I know there already great extensions out there that work within this
system, but its confusing. Is there any thought about rewriting the
chrome to use something... simpler? Or at least renaming the files
with a name that's more helpful?
0
holden101
2/8/2008 6:01:07 PM
holden101@gmail.com wrote:
> On Jan 28, 4:53 pm, David Ascher <david.asc...@gmail.com> wrote:
>   
>>  - 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
>>     
> David -
>
> Does this refactoring include any changes to the TB chrome structure?
>   

Sounds like a fine idea in general.  I don't have an opinion on the 
details, but I'm sure others will.  In general, I suspect that those 
kinds of refactorings are a fine idea, we just need to do them in a 
rational way.  If you have specific ideas, feel free to build a wiki 
page about a plan that people can discuss, and we can incorporate that 
into the overall roadmap. 

--david

0
David
2/8/2008 6:25:07 PM
On Jan 28, 11:53=A0pm, David Ascher <david.asc...@gmail.com> wrote:
> 1. Thunderbird's impact is proportional to its user count. =A0Thus driving=

> adoption is my primary concern. =A0Our 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.

Here in The Netherlands Outlook is heavily used in almost every
company because of its shared calendar functions and its integration
in to Microsoft's Active-Directory. If Thunderbird would make use of
this Exchange Calendar system, it will be the first step to take over
the desktop in these companies.

Remember: Most users make use of an e-mail client for private e-mail
that they used to work with (like they the one they have to use for
work). System administrators are willing to install new (better)
software if migration is simple and critical functions will still be
available.


0
miami
2/11/2008 11:50:45 AM
 > > - Corporate users:
>
> > 1. Sync the calendar with Exchange, without needing Outlook. Use OWA
> >    or a provider to sync with the Exchange calendar;

Why not go on with your own solution, proposing a client (TB) + server
(Davical?) + directory (openldap, fds?) or whatever combination is
possible? There's a wonderful world out there: SynML, Imap, Groupware,
etc.

It would be great  to create alternatives for corporations, not for
corporate users only....

Thanks for your great job!
0
lorenzo
2/14/2008 6:12:33 PM
Chris Ilias wrote:
> _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.


Hosting software CPanel has a client setup feature which offers
a menu of config files
http://www.cpanel.net/support/docs/11/cpanel/mail_config.html


<<
   	Configuring Mail Client for user@example.com
	

Please select an application:

Auto-Configure Microsoft Outlook� for IMAP Access
Auto-Configure Microsoft Outlook� for POP3 Access
Auto-Configure Microsoft Outlook Express� for IMAP Access
Auto-Configure Microsoft Outlook Express� for POP3 Access
Auto-Configure Mac Mail.app� for IMAP Access
 >>

The above are clickable links which load down an autoconfigure file.
For the Windows apps, they appear to be .reg files which load entries
into the registry? :-O   The Mail.app selection loads down a zipped
..app file which it must generate on the fly?  Adding TB/SM would be
sweet.  (Well, SM would be suite ;p)


-- 
Rich        (Pull thorn from address to e-mail me.)
SeaMonkey - Surfing the net has never been so suite!
0
Rich
2/22/2008 2:55:33 AM
I'm coming at this as a SeaMonkey user, but I think all the
things here are pretty much mailnew core.

Peter Lairo wrote:
> I would much rather see Thunderbird's very limited resources be used on 
> (IMO more important) things like:
> 
> Ignore (kill) a Subthread (branch: not the whole thread)
> https://bugzilla.mozilla.org/show_bug.cgi?id=11054

Yes!  This and the already landed
16913 Filter news based on any headers
https://bugzilla.mozilla.org/show_bug.cgi?id=16913 will
make the newsreader function in TB/SM "respectable".
Without them, I've had a hard time chiming in when
threads pop up in various newsgroups asking for
newsreader recommendations.

> Add birthday fields to address book
> https://bugzilla.mozilla.org/show_bug.cgi?id=13595

Also "AB should "enable" the <category> item at UI-level for
display and searching"
https://bugzilla.mozilla.org/show_bug.cgi?id=364152

We make major use of categorization for each other's
families, physicians & legal, friends, etc.   I think
I could get my wife away from Palm Desktop if AB
supported all the fields PD does and has reasonable
view and print options.  (The print format seems
sparse to me.   I'd like more entries per page.)

> Use a SQLite Database for Storing Mails
> https://bugzilla.mozilla.org/show_bug.cgi?id=361807

Bad idea.  One of the problems with the current mbox
scheme is that mail is not handled well by incremental
backups like OS X's shiny new Time Machine.  Nor is it
easily indexed by the likes of Mac Spotlight.  Maildir
sounds like a good idea, perhaps using SQLite to index,
etc.


> Need: View -> Messages -> Watched Thread (ALL, not just "Unread")
> https://bugzilla.mozilla.org/show_bug.cgi?id=294901

I usually go through newsgroups with "unread" or "threads
with unread".  There does not seem to be a good way to
tag a message with a "stay visible" attribute so I can come
back to it later and is not forgotten.   Tags don't seem
to be quite the answer.   I don't want to have to change
view to tagged items, etc to remember stuff.   Maybe
view options should allow multiple selections which would
be ORed:

[*] Unread
[*] Watched
[*] Flagged, err, Stared
[ ] Tagged

With the above settings, watched threads, unread messages and Flagged/
Starred messages would be visible.   An alternate approach might allow
a "sticky" attribute to be attached to selected items.   One could
designate Star/Flag and desired Tags as sticky, then have a Stickies
option in View.   When this was requested, any Stared/Flagged or Tagged
option designated as Sticky, would stay visible, without the finagling
of trying to keep an interesting post unread.

It might be helpful if navigating back up a thread were easier.
I notice that NS style references are back on trunk.  Yay!  But
if one clicks on a reference for a message that is not in the current
view (for example, it has been read and the view is for unread), it
does not get displayed!  I think it should.   Perhaps a simple option
to expand and display just the current thread (as opposed to Expand
All Threads) would help.

Another major navigational annoyance is the fact that changing View
will usually lose the current message.   I go reading into an old
thread with Unread, and find the thread interesting.  So I change the
view to Threads with Unread to go backwards and I'm rewarded by losing
my place and if the message was the last unread, it will now be read
and the thread will disappear!  Suggested rules:

1. The current message position is retained across view changes
2. The current message remains visible even if it should be invisible
    due to a view change.

Sorry I haven't had a chance to try to look this later stuff up in
Bugzilla.  I wanted to get it posted before another week goes by.

-- 
Rich        (Pull thorn from address to e-mail me.)
SeaMonkey - Surfing the net has never been so suite!
0
Rich
2/25/2008 2:18:08 AM
Archaeopteryx aber hob zu reden an und schrieb:
> 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

Mailservers usually don't support http. :-P

But given the mail server's name, it might be possible to sniff for
(standard) POP3/IMAP configurations.


Karsten
-- 
Feel free to correct my English. :)
0
ISO
3/1/2008 3:52:56 PM
Karsten D�sterloh wrote:
> Archaeopteryx aber hob zu reden an und schrieb:
>    
>> 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
>>      
>
> Mailservers usually don't support http. :-P
>    

I would think that if given foo@example.com, we could look in 
http://mailconfig.example.com/config/foo

or some other arbitrary URL.

Depending on what one can do with DNS, there's also the idea of 
specifying where to look for config information using new DNS records, 
but that strikes me as much harder to deploy than specifying a convention.
> But given the mail server's name, it might be possible to sniff for
> (standard) POP3/IMAP configurations.
>    

Definitely.  iPhone and Mail.app both do a remarkable job there.  I was 
at the MAAWG conference (which is a bunch of anti-malware people trying 
to work together), and that's one of the specific requests I got: 
"please do what you can to move people away from port 25" (and onto more 
secure ports).

-david

0
David
3/1/2008 7:58:11 PM
David Ascher wrote:
> I would think that if given foo@example.com, we could look in
> http://mailconfig.example.com/config/foo

If you mean what I think you do, the /robots.txt antipattern, no, no we 
couldn't. That's a pile of bodies laying down in the road that you do 
not want to drive over. The days when you could order people to arrange 
their URIs to suit you are over, and no, people will not think that a 
few (dozen, hundred, million (how many addresses do hotmail, yahoo, aol, 
and gmail have?)) 404 requests to an arbitrary URI of your choice on 
their server are acceptable.
0
Phil
3/2/2008 4:48:01 AM
Phil Ringnalda wrote:
> David Ascher wrote:
>    
>> I would think that if given foo@example.com, we could look in
>> http://mailconfig.example.com/config/foo
>>      
>
> If you mean what I think you do, the /robots.txt antipattern, no, no we
> couldn't. That's a pile of bodies laying down in the road that you do
> not want to drive over. The days when you could order people to arrange
> their URIs to suit you are over, and no, people will not think that a
> few (dozen, hundred, million (how many addresses do hotmail, yahoo, aol,
> and gmail have?)) 404 requests to an arbitrary URI of your choice on
> their server are acceptable.

Yah, that wasn't really a serious proposal as stated.

There are all kinds of alternatives, and all kinds of ways to mitigate 
the downsides of each alternative.  Regardless, I think that helping 
users with configuration is a huge opportunity for us.  Port-sniffing is 
clearly a "safe" win, and _we should do it_ but it only gives us so 
much.  There are lots of other configuration switches which ISPs (and 
enterprises) would really like to have as easily configured as possible.

Others have already mentioned that hosting configuration files on a 
mozilla run server is also an alternative for cooperating ISPs (or ISPs 
with cooperating users?).

Maybe a hybrid model would be worth looking at:  e.g. given 
jane@example.com, GET 
http://mailconfigs.mozilla.org/thunderbird/domain/example.com.  That 
could either be configuration data for example.com, or (if example.com 
chose to), a URL to a page owned by example.com.  Many devils in 
numerous details.

That's longer term, though.  At this stage I'd be very happy with a 
better account setup wizard which did smart port and "common-hostname" 
sniffing.  If there are any takers, I know someone with some alpha code 
that already does some of that.

--david
0
David
3/2/2008 7:57:23 PM
David Ascher aber hob zu reden an und schrieb:
>>> I would think that if given foo@example.com, we could look in
>>> http://mailconfig.example.com/config/foo
....
> Yah, that wasn't really a serious proposal as stated.

Good. :)

Because it suspiciously sounded like MicroSoft's idea of looking for
favicons on each domain hit (although on a much lesser scale - once on
account creation -, but with more "offtargetness")...

> There are all kinds of alternatives, and all kinds of ways to mitigate 
> the downsides of each alternative.  Regardless, I think that helping 
> users with configuration is a huge opportunity for us.  Port-sniffing is 
> clearly a "safe" win, and _we should do it_ but it only gives us so 
> much.  There are lots of other configuration switches which ISPs (and 
> enterprises) would really like to have as easily configured as possible.

The question is, how to make those ISPs structure their (customer's)
websites in a way _we_ define...
We do have the "ISP hooks" mechanism
<http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>, but AFAICT
it's not exactly used much and rather clumsy (the RDF file needs to be
manually copied or the ISP needs to deploy an extension).

> Others have already mentioned that hosting configuration files on a 
> mozilla run server is also an alternative for cooperating ISPs (or ISPs 
> with cooperating users?).

Could be hard for Mozilla to run the world of email configuration. ;-)

Maybe it'd be worth to talk to other mailer folks/ISPs and come up with
a common proposal? (Dunno how the prospects are for that, the ISP I'm
working for is probably a bit too small to have a real impact. ;-) )

> That's longer term, though.  At this stage I'd be very happy with a 
> better account setup wizard which did smart port and "common-hostname" 
> sniffing.  If there are any takers, I know someone with some alpha code 
> that already does some of that.

Alpha code for Mozilla or in general?


Karsten
-- 
Feel free to correct my English. :)
0
ISO
3/2/2008 10:55:26 PM
Karsten D�sterloh wrote:
> David Ascher aber hob zu reden an und schrieb:
>    
>>>> I would think that if given foo@example.com, we could look in
>>>> http://mailconfig.example.com/config/foo
>>>>          
> ...
>    
>> Yah, that wasn't really a serious proposal as stated.
>>      
>
> Good. :)
>
> Because it suspiciously sounded like MicroSoft's idea of looking for
> favicons on each domain hit (although on a much lesser scale - once on
> account creation -, but with more "offtargetness")...
>    

Please, let's start with giving each other the benefit of the doubt =).

> The question is, how to make those ISPs structure their (customer's)
> websites in a way _we_ define...
> We do have the "ISP hooks" mechanism
> <http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>, but AFAICT
> it's not exactly used much and rather clumsy (the RDF file needs to be
> manually copied or the ISP needs to deploy an extension).
>    

Right, I think the intent there was good, but the execution needs work.  
So what I'm wondering in general is if a user (or an admin) at some ISP 
wants to make it easy to let their users autoconfigure Thunderbird, 
whether there is a way where we could host some files (or if they'd 
rather, URLs to files they host wherever) which aid in that effort.  
That's all I'm trying to express.

> Could be hard for Mozilla to run the world of email configuration. ;-)
>    

I don't intend that either -- only to help people help themselves.  
Strictly opt-in.
> Maybe it'd be worth to talk to other mailer folks/ISPs and come up with
> a common proposal? (Dunno how the prospects are for that, the ISP I'm
> working for is probably a bit too small to have a real impact. ;-) )
>    

Think of it as some of the more informal markup proposals (I'm thinking 
of rel="nofollow", although maybe with less political hoopla).
>    
>> That's longer term, though.  At this stage I'd be very happy with a
>> better account setup wizard which did smart port and "common-hostname"
>> sniffing.  If there are any takers, I know someone with some alpha code
>> that already does some of that.
>>      
>
> Alpha code for Mozilla or in general?
>    

Alpha Thunderbird extension.  I'll see if I can get that released 
somewhere for discussion.

--david
0
David
3/2/2008 11:20:13 PM
David Ascher aber hob zu reden an und schrieb:
> So what I'm wondering in general is if a user (or an admin) at some ISP 
> wants to make it easy to let their users autoconfigure Thunderbird, 
> whether there is a way where we could host some files (or if they'd 
> rather, URLs to files they host wherever) which aid in that effort.  

Given my experience, many users don't actually understand most fields
they need to fill in on account creation, so any field less is a good
thing, especially since this takes load off the ISP's helpdesk.

>> Could be hard for Mozilla to run the world of email configuration. ;-)
> 
> I don't intend that either -- only to help people help themselves.  
> Strictly opt-in.

Sure. I just feared the success of it for your hardware. ;-)

>> Maybe it'd be worth to talk to other mailer folks/ISPs and come up with
>> a common proposal? (Dunno how the prospects are for that, the ISP I'm
>> working for is probably a bit too small to have a real impact. ;-) )
> 
> Think of it as some of the more informal markup proposals (I'm thinking 
> of rel="nofollow", although maybe with less political hoopla).

My main concern is generating useless http hits for failed sniffing.
This could maybe alleviated by expecting the stuff on a certain
subdomain, eg "if mozillamailconfig.example.com exists, load config file
from there".


Karsten

PS: no need to reply per mail, I'm reading the newsgroup.
-- 
Feel free to correct my English. :)
0
ISO
3/2/2008 11:35:23 PM
Karsten D�sterloh wrote:
> David Ascher aber hob zu reden an und schrieb:
>    
>> So what I'm wondering in general is if a user (or an admin) at some ISP
>> wants to make it easy to let their users autoconfigure Thunderbird,
>> whether there is a way where we could host some files (or if they'd
>> rather, URLs to files they host wherever) which aid in that effort.
>>      
>
> Given my experience, many users don't actually understand most fields
> they need to fill in on account creation, so any field less is a good
> thing, especially since this takes load off the ISP's helpdesk.
>
>    
>>> Could be hard for Mozilla to run the world of email configuration. ;-)
>>>        
>> I don't intend that either -- only to help people help themselves.
>> Strictly opt-in.
>>      
>
> Sure. I just feared the success of it for your hardware. ;-)
>    

I'm pretty sure we can handle an HTTP GET for every user on the planet 
each time they configure an account.  Let's put it this way -- if we 
have a hardware problem there, then it's because we're succeeding.  I'd 
_love_ to have hardware be the issue there =)
> My main concern is generating useless http hits for failed sniffing.
> This could maybe alleviated by expecting the stuff on a certain
> subdomain, eg "if mozillamailconfig.example.com exists, load config file
> from there".
>    

I think http hits are at least 6 orders of magnitude easier to deal with 
than forum posts asking for help. =)

--david

0
David
3/3/2008 12:24:52 AM
Karsten D�sterloh on 02.03.2008 23:55 wrote:
> The question is, how to make those ISPs structure their (customer's)
> websites in a way _we_ define...
> We do have the "ISP hooks" mechanism
> <http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks>, but AFAICT
> it's not exactly used much and rather clumsy (the RDF file needs to be
> manually copied or the ISP needs to deploy an extension).

I just edited that web page with the following suggestion (hope that was 
OK):

Alternatively, to accommodate for a larger number of ISPs, the dialog 
could look like this:

+-------------------------------------------------+
| Account Wizard                                  |
~                                                 ~
| (o) E-Mail account                              |
|     (o) Custom settings                         |
|     ( ) Pre-configured e-mail providers (ISPs)  |  <--- NEW
|         +-------------------------------------+ |
|         | fastmail.fm                       /\| |
|         | freenet.de                        ||| |
|         | Google Mail (gmail)               ||| |
|         | gmx.de                            \/| |
|         +-------------------------------------+ |
|     ( ) Import settings from a file             |  <--- NEW
| ( ) RSS News Feeds and Blogs                    |
| ( ) Newsgroup account                           |
|                                                 |
|                  [ Back ]  [ Next ]  [ Cancel ] |
+-------------------------------------------------+

The pre-configured list could either be hard-coded into the current 
Thunderbird release (requires no internet connection but is not 
up-to-date), or it could be downloaded from a server (requires internet 
connection but is up-to-date). Perhaps the list could also auto-filter 
on whatever locale the OS reports (e.g., German users get only German 
ISPs plus the major international ISPs).
-- 
Regards,

Peter Lairo

The browser you can trust:  www.GetFirefox.com
Reclaim Your Inbox:         www.GetThunderbird.com

Israel - Myths & Facts:     http://www.JewishVirtualLibrary.org/
Dangers of Islam (German):  http://www.pi-news.net/
Church of the Flying Spaghetti Monster:  http://www.venganza.org/
0
Peter
3/3/2008 3:03:32 PM
Hi Peter,

Peter Lairo:
>
> The pre-configured list could either be hard-coded into the current 
> Thunderbird release (requires no internet connection but is not 
> up-to-date), or it could be downloaded from a server (requires internet 
> connection but is up-to-date). Perhaps the list could also auto-filter 
> on whatever locale the OS reports (e.g., German users get only German 
> ISPs plus the major international ISPs).
>   
I'm not sure if this is the right approach, I'd rather expect at the 
accounts wizard would offer an option to enter a URL for the location of 
the configuration file(s) of particular ISPs. There are tens of 
thousands of ISPs and hosting providers which at some point would like 
to have their config listed in TB, which in turn would require from us 
to define a criteria for it, and require a high overhead to maintain 
such a list.

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
3/3/2008 6:28:57 PM
On 2008-03-03 20:28, Eddy Nigg (StartCom Ltd.) wrote:
>> The pre-configured list could either be hard-coded into the current
>> Thunderbird release (requires no internet connection but is not
>> up-to-date), or it could be downloaded from a server (requires
>> internet connection but is up-to-date). Perhaps the list could also
>> auto-filter on whatever locale the OS reports (e.g., German users get
>> only German ISPs plus the major international ISPs).
> I'm not sure if this is the right approach, I'd rather expect at the
> accounts wizard would offer an option to enter a URL for the location of
> the configuration file(s) of particular ISPs. There are tens of
> thousands of ISPs and hosting providers which at some point would like
> to have their config listed in TB, which in turn would require from us
> to define a criteria for it, and require a high overhead to maintain
> such a list.

I think only using user submitted data will get any decent ISP coverage.

We should have (a mozilla messaging hosted) configuration repository to which 
users could submit data for their domain. If we require that the servers have 
the same domain as the e-mail address, I think there aren't many security 
problems left.

  -Magnus



0
Magnus
3/3/2008 8:02:51 PM
On 3/3/08 10:03 AM, _Peter Lairo_ spoke thusly:
> The pre-configured list could either be hard-coded into the current 
> Thunderbird release (requires no internet connection but is not 
> up-to-date), or it could be downloaded from a server (requires internet 
> connection but is up-to-date). Perhaps the list could also auto-filter 
> on whatever locale the OS reports (e.g., German users get only German 
> ISPs plus the major international ISPs).

I would reverse the order in which the Account Wizard asks for info. If 
you ask for the identity name and email address first, you can fetch the 
ISP hook, based on the email address entered.
-- 
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
0
Chris
3/3/2008 11:46:02 PM
On Jan 31, 5:05 pm, Thomas <KWERBtwildeb...@gmx.de> wrote:
> Simon Paquet schrieb:
>
> >> Another reason why people don't use TB are the missing fields in
> >> addressbook.
>
> > I seriously doubt that this is a serious showstopper all by itself.
> > It's annoying for sure, but I find it hard to believe that someone
> > would not use Thunderbird just because of this.
>
> hmm, I am "someone" who won't use TB for mail because of missing fields
> in addressbook. :-(
>
> Until yet I am using Outlook 2000, but I am looking for an alternative,
> which handles also my calender andcontacts. Because of thecontactsI
> won't move to TB. The calender-functionality of Lightning is great, if
> alsobirthdayswill be handled by TB and Lightning.
>
> Thomas

Yes, I would love to see the birthday field in the contacts and then
also have them display in Lightning without using a third party
plugin.
0
kismeras
3/4/2008 4:27:14 AM
Magnus Melin wrote:
> I think only using user submitted data will get any decent ISP coverage.
>
> We should have (a mozilla messaging hosted) configuration repository to
> which users could submit data for their domain.

Yeah, this seems to do very well at taking advantage of the knowledge 
distributed across the userbase.  This repository might want to be 
hosted as DNS-SD data <http://www.dns-sd.org/>.

Supporting DNS SRV records might also be interesting here.

However, doing either of those things would require more sophisticated 
DNS resolution be implemented in Necko (something that I think is worth 
doing for various other reasons as well).  It might well be possible to 
do this by finding and wrapping an existing open-source resolver 
library.  However, this is probably a decent amount of work, so we also 
might do well to consider figuring out / finding some other 
(HTTP-based?) mechanism.

Dan
0
Dan
3/4/2008 5:59:32 AM
Chris Ilias on 04.03.2008 00:46 wrote:
> On 3/3/08 10:03 AM, _Peter Lairo_ spoke thusly:
>> The pre-configured list could either be hard-coded into the current 
>> Thunderbird release (requires no internet connection but is not 
>> up-to-date), or it could be downloaded from a server (requires 
>> internet connection but is up-to-date). Perhaps the list could also 
>> auto-filter on whatever locale the OS reports (e.g., German users get 
>> only German ISPs plus the major international ISPs).
> 
> I would reverse the order in which the Account Wizard asks for info. If 
> you ask for the identity name and email address first, you can fetch the 
> ISP hook, based on the email address entered.

Good idea. But some ISPs have a long list of possible domains, while 
their IMAP/SMTP servers are only on their one main domain (e.g., I have 
a fastmail.fm account, but my e-mail address from them is 
foobar@123mail.org). How would you solve that?
-- 
Regards,

Peter Lairo

The browser you can trust:  www.GetFirefox.com
Reclaim Your Inbox:         www.GetThunderbird.com

Israel - Myths & Facts:     http://www.JewishVirtualLibrary.org/
Dangers of Islam (German):  http://www.pi-news.net/
Church of the Flying Spaghetti Monster:  http://www.venganza.org/
0
Peter
3/4/2008 3:36:56 PM
Peter Lairo:
>
> Good idea. But some ISPs have a long list of possible domains, while 
> their IMAP/SMTP servers are only on their one main domain (e.g., I have 
> a fastmail.fm account, but my e-mail address from them is 
> foobar@123mail.org). How would you solve that?
>   
The DNS zone for 123mail.org has an MX entry. Supposed the MX is 
fastmail.fm. then it must also have a TXT record for the mail ISP 
discovery file.
Optionally an SVR record could be used, but I guess this will start to 
be too complicated.

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
3/4/2008 6:35:47 PM
I'm not sure whether this is the right location to comment or not.
Though I use computers a lot and am more adept than most of my
colleagues, I still haven't figured out the whole Thunderbird/Firefox
bug/input process so have never previously offered any feedback.

I've used Thunderbird for years and love it! I access it from a
central server using IMAP and have a huge database of emails saved
(>10,000) in which I routinely need to search for information.

I still find it much more efficient to find what I need in Thunderbird
compared to other options.  But ...

a. the positioning of the search messages command under Edit is very
counterintuitive (even after years of using the program, I keep
wanting to look under "Message", suggesting to me that this is a
usability issue)
b. the searches are very slow
c. in the list of found emails, the sorting doesn't always work
properly (if you click at the top of the column to sort by date, for
example, it doesn't sort the whole column but appears to sort by
folder-based subsets of the column)
d. it would be nice to be able to preview the found messages (as in
the regular email preview pane) to rapidly locate the specific email
that you want (having to open each one individually is time
consuming).

Thanks for all of your work to make and keep this a great product!

0
drlorky
3/17/2008 6:26:14 PM
Hi David,

I just eagerly read your suggestions on the roadmap for the future
thunderbird development.

And I want to stress the importance of a good /contact manager/ as
well !
There is still big room of improvement here too.
And if you are targeting the people using PIMs (like outlook), this is
for many as important as the calendar (from my humble experience with
many users).
E.g. layout of the contacts (different (over)views) and especially a
better (selection of) printing layout(s)!

So hope you may put these points into consideration.

Greetings,

quickhelp :-)

---

On Jan 28, 6:53 pm, David Ascher <david.asc...@gmail.com> wrote:
> 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.
>
> 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 ishttp://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

0
picasa
3/19/2008 4:28:32 AM
drlorky@gmail.com wrote:
> I'm not sure whether this is the right location to comment or not.
>
>   
there are some options, like bugzilla.mozilla.org (place for feature 
request also..)
or having here a new thread (better than inside this one, maybe) to see 
if those are in process or to better define those before going to 
bugzilla to find if there are already some ..
also a group called mozilla.wishlist
> a. the positioning of the search messages command under Edit is very
> counterintuitive (even after years of using the program, I keep
> wanting to look under "Message", suggesting to me that this is a
> usability issue)
>   
I think this immitates a common "find" under edit found in most of apps, 
at least in windows.
> b. the searches are very slow
>   
I think there is an "better search" goal for TB3 as stated in this 
thread OP.
> c. in the list of found emails, the sorting doesn't always work
> properly (if you click at the top of the column to sort by date, for
> example, it doesn't sort the whole column but appears to sort by
> folder-based subsets of the column)
>   
same above
> d. it would be nice to be able to preview the found messages (as in
> the regular email preview pane) to rapidly locate the specific email
> that you want (having to open each one individually is time
> consuming).
>   
that is a tricky one. what if having found 30 results ?

for extra info see in this very group the recent threads on
-Seek: faceted browsing in Thunderbird
-TB UI enhancements: Vertical view & inline message
0
ovidiu
3/19/2008 9:02:54 AM
On Jan 28, 10:53 pm, David Ascher <david.asc...@gmail.com> wrote:
> * Less user-visible but important goals include:
>  - Significant headway on getting rid of Mork and RDF

There was also mention of moving to sqllite based storage.

I like to advocate moving to a non-monolithic mail storage mechanism,
be that maildir or something else.  Recent OS are adding better
automated backup and archiving systems, e.g. window's shadow copy,
apple's time machine and other copy on write FS.  Having a complete
email database of several gigabytes duplicated because of a few new
emails is a real pain and even with ever cheaper disk storage the
email db will still end up grabbing the majority of the available
space for many people.

This was a show stopper for me.  I've recently moved away from
Thunderbird to Mail.app because of it.

I'd also like to reiterate the points about, IMAP, calendars and
outlook.  I support IT for various small businesses, although I'd love
to recommend Thunderbird (or anything) over Outlook - due to Outlook's
appalling IMAP support - I can't without a credible calendar &
addressbook alternative.
0
chris
3/22/2008 4:32:12 PM
chris.jalakai@googlemail.com wrote:
> On Jan 28, 10:53 pm, David Ascher<david.asc...@gmail.com>  wrote:
>> * Less user-visible but important goals include:
>>   - Significant headway on getting rid of Mork and RDF
>
> There was also mention of moving to sqllite based storage.
>
> I like to advocate moving to a non-monolithic mail storage mechanism,

Erm, the current format _is_ non-monolithic, by not having one email 
database but one (mbox) file per email folder, which is usually a good 
compromise between one large DB in Outlook style and huge amounts of 
separate files like in the maildir format (stat'ing/accessing lots of 
files is a quite slow operation on many modern filesystems, esp. with 
the metadata/acl overhead that really modern filesyems apply to every 
single file).

Current plans are neither going to a monolithic database nor to hordes 
of files but staying with this middle path. One day, maildir might be 
added as an additional option, but saving everything in one huge 
database is out of the question, from what I hear (thankfully).

What we are planning is to move metadata (message summary files, .msf 
files in current Thunderbird/SeaMonkey profiles) from mork to a more 
saner SQLite format, but thoe only store data for fast buildup of 
message lists and things like message tags - but _not_ the actual email 
data, which stays in the one-file-per-folder mbox structure.

Robert Kaiser
0
Robert
3/22/2008 5:06:05 PM
On Sat, Mar 22, 2008 at 6:06 PM, Robert Kaiser <kairo@kairo.at> wrote:
> chris.jalakai@googlemail.com wrote:
>  > On Jan 28, 10:53 pm, David Ascher<david.asc...@gmail.com>  wrote:
>  >> * Less user-visible but important goals include:
>  >>   - Significant headway on getting rid of Mork and RDF
>  >
>  > There was also mention of moving to sqllite based storage.
>  >
>  > I like to advocate moving to a non-monolithic mail storage mechanism,
>
>  Erm, the current format _is_ non-monolithic, by not having one email
>  database but one (mbox) file per email folder, which is usually a good
>  compromise between one large DB in Outlook style and huge amounts of
>  separate files like in the maildir format (stat'ing/accessing lots of
>  files is a quite slow operation on many modern filesystems, esp. with
>  the metadata/acl overhead that really modern filesyems apply to every
>  single file).

deleting a message in a mbox is a pain.
it needs a final rewrite of the mbox.
Cyrus IMAP server has good performance by using a database file (per
mailbox) to reference the messages
and one file per message.
To get an efficient search, I think a unique database per account
should be worth the try
(To get the list of unread messages for example, a SELECT messages
where read_flag=3D0).
That would avoid performing the request for each folder.

--=20
DINH Vi=EAt Ho=E0
0
ISO
3/23/2008 8:32:11 AM
DINH Vi�t Ho� schrieb:
> deleting a message in a mbox is a pain.
> it needs a final rewrite of the mbox.

True, but that should be done by our app in the background and need not 
concern the normal user (IMHO, compacting should be done by default in 
idle periods)

> Cyrus IMAP server has good performance by using a database file (per
> mailbox) to reference the messages
> and one file per message.

True, but its performance degrades with the amount of metadata the 
filesystem stores (luckily, it usually runs on typical unix filesystems 
that are very lightweight in metadata, unlike NTFS or even the future 
WinFS).

> To get an efficient search, I think a unique database per account
> should be worth the try
> (To get the list of unread messages for example, a SELECT messages
> where read_flag=0).

That's planned with SQLite summary databases anyway, which should 
replace the current mork summary files one day.

Robert Kaiser
0
Robert
3/23/2008 11:56:54 AM
DINH Vi�t Ho� wrote:
> To get an efficient search, I think a unique database per account
> should be worth the try
> (To get the list of unread messages for example, a SELECT messages
> where read_flag=0).
> That would avoid performing the request for each folder.

A message database per account has been requested numerous times and I 
think all developers are in favor of this in the mid-to-long term; such 
a setup would make fixing several enhancements easier (better xposts in 
newsgroups is one example). That said, the current consensus is to delay 
this feature until after Thunderbird 3 to try to limit the number of 
reorganizations going on at this time.
0
Joshua
3/23/2008 4:42:49 PM
Reply:

Similar Artilces:

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 217422] Patch against current b #3
Josh Aas <joshmoz@gmail.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 217422: Patch against current branch files https://bugzilla.mozilla.org/attachment.cgi?id=217422&action=edit ...

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 220339] Patch that uses MOZ_APP #3
David Bienvenu <bienvenu@nventure.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 220339: Patch that uses MOZ_APP_DISPLAYNAME for executable https://bugzilla.mozilla.org/attachment.cgi?id=220339&action=edit ------- Additional Comments from David Bienvenu <bienvenu@nventure.com> you need to request reviews of people - bugzilla should really complain about that! ...

Thunderbird to Thunderbird
Our laptop went bad but hard drive is good and have accessed it. How do I transfer the email etc. from the old laptop to a desktop computer with a fresh install of thunderbird? Thank you! zparky wrote: > Our laptop went bad but hard drive is good and have accessed it. How do > I transfer the email etc. from the old laptop to a desktop computer with > a fresh install of thunderbird? > Thank you! Find your profile folder on the old drive. (This will help you find it: http://kb.mozillazine.org/Profile_folder_-_Thunderbird Use the instructions for Vista if you are...

Thunderbird 3 vs Thunderbird 2
Guys, I just tried upgrading from Thunderbird 2 to 3 beta (using Fedora rawhide which uses Thunderbird 3 beta 2). Now I thought I'd post something peculiar I found concerning posting to newsgroups (and apparently also SMTP sending). I have set up in my setting for the newsgroup to use my outgoing SMTP server. This SMTP server is to use authentication. After upgrade to Thunderbird 3, I couldn't post or send emails... My SMTP server doesn't support authentication! I used Wireshark to trace where TB2 was sending my news posts. According to the packets I captured T...

Thunderbird 3 planning
[I'd forgotten to include seamonkey on the list, so posting here as well, followup to thunderbird newsgroup. Apologies. --da] 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. Note: I'm cross-posting this to the planning, calendar[, seamonkey] 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 ne...

Thunderbird 3 Bugday, Thursday 3/12
Thunderbird, Seamonkey, Calendar users ... you can help. Focus continues on improving and resolving bugs reported against trunk (v3). If you haven't participated yet, now is a good time to dip your toes into bug triage. You don't have to be running trunk to help. You can get advice on IRC in #bugday. http://wiki.mozilla.org/Thunderbird:QA_TestDay:2009-03-12 has tips and starting points. Please join us this Thursday in #bugday! Ludovic -- Ludovic Hirlimann MozillaMessaging QA lead http://www.spreadthunderbird.com/aff/79/2 ...

Thunderbird 3 Bugday, Thursday 3/19
Thunderbird, Seamonkey, Calendar users ... you can help. Focus continues on improving and resolving bugs reported against trunk (v3). If you haven't participated yet, now is a good time to dip your toes into bug triage. You don't have to be running trunk to help. You can get advice on IRC in #bugday. http://wiki.mozilla.org/Thunderbird:QA_TestDay:2009-03-19 has tips and starting points. Please join us this Thursday in #bugday! Ludovic -- Ludovic Hirlimann MozillaMessaging QA lead http://www.spreadthunderbird.com/aff/79/2 ...

Thunderbird 3 Bugday, Thursday 3/05
Thunderbird, Seamonkey, Calendar users ... you can help. Focus continues on improving and resolving bugs reported against trunk (v3). If you haven't participated yet, now is a good time to dip your toes into bug triage. You don't have to be running trunk to help. You can get advice on IRC in #bugday. http://wiki.mozilla.org/Thunderbird:QA_TestDay:2009-08-27 has tips and starting points. Please join us this Thursday in #bugday! Ludovic http://wiki.mozilla.org/Thunderbird:Testing lists additional ways to contribute to Thunderbird's progress. -- Ludovic Hirlim...

Thunderbird 3 Bugday, Thursday 3/05
Thunderbird, Seamonkey, Calendar users ... you can help. Focus continues on improving and resolving bugs reported against trunk (v3). If you haven't participated yet, now is a good time to dip your toes into bug triage. You don't have to be running trunk to help. You can get advice on IRC in #bugday. http://wiki.mozilla.org/Thunderbird:QA_TestDay:2009-02-12 has tips and starting points. Please join us this Thursday in #bugday! Ludovic http://wiki.mozilla.org/Thunderbird:Testing lists additional ways to contribute to Thunderbird's progress. -- Ludovic Hirlim...

Profile migration from Thunderbird 2 to Thunderbird 3
Can I copy & paste the profile directory from Thunderbird 2 to Thunderbird 3 and it will work, or is there another better way? Thanks. On 15/12/09 23:24, Julián Mejio Cárdenas wrote: > Can I copy & paste the profile directory from Thunderbird 2 to > Thunderbird 3 and it will work, or is there another better way? There should be nothing to do. Just install 3 and run it. Ludo -- Ludovic Hirlimann MozillaMessaging QA lead http://www.spreadthunderbird.com/aff/79/2 El 2009-12-17 08:05, Ludovic Hirlimann escribió: > On 15/12/09 23:24, Julián M...

Thunderbird 3 #3
Name: Barb Harding Email: babbetskiatyahoodotcom Product: Thunderbird Summary: Thunderbird 3 Comments: I do not like the 5 buttons that you put on the "view email screen" and I don't like the way the new window pops up when an email is clicked. Is there a "theme" that I can click on to make Thunderbird appear to look like 2? The buttons are very distracting from the email reading. I really can't stand it. I forced my son and husband to regress back to 2. Please help! I'm one of those annoying users that don't like a lot of ch...

Thunderbird 3 #3
I assume that the question has been asked numerous times, but when are we going to see the final release of Thunderbird 3? I've been waiting for so long, it's been delayed so many times... Thanks, F. user@domain.invalid on 9/21/2009 2:06 PM, keyboarded a reply: > I assume that the question has been asked numerous times, but when are > we going to see the final release of Thunderbird 3? I've been waiting > for so long, it's been delayed so many times... > Thanks, > F. Well it will happen before the day You die. :) It is getting close. The Beta...

Proposal: Upgrade Thunderbird's MozMill version to 1.3 after Thunderbird 3.1a1 is cut/branched
Currently the Thunderbird Mozmill Tests [1] require running on MozMill 1.2 (with jsbridge 2.0 and mozrunner 1.2.1.1). We'd like to update this to the latest MozMill - 1.3 [2] . However, because some of the command-line options have changed, we cannot support running of MozMill 1.2 instead. I don't see any barriers to doing this upgrade - there aren't any other compatibility issues with this upgrade. I'm proposing that we upgrade soon after the Thunderbird 3.1a1 branch is cut and before we reopen the tree, which will probably be on or before Tuesday. When...

superreview denied: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 217422] Patch against current bran
Mark Mentovai <mark@moxienet.com> has denied Josh Aas <joshmoz@gmail.com>'s request for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 217422: Patch against current branch files https://bugzilla.mozilla.org/attachment.cgi?id=217422&action=edit ------- Additional Comments from Mark Mentovai <mark@moxienet.com> The app bundle's name is ThunderbirdDebug during a debug build. I'd be pleased to...

Web resources about - Thunderbird 3 Planning - mozilla.dev.apps.thunderbird

Mozilla Thunderbird
Mozilla Thunderbird is created by a global non-profit dedicated to putting individuals in control and shaping the future of the web for the public ...

Thunderbirds Are Go - Wikipedia, the free encyclopedia
Thunderbirds Are Go is a 1966 British science-fiction film based on Thunderbirds , a 1960s television series starring marionette puppets and ...

Edit - Thunderbird - CrunchBase Product Profile
TechCrunch CrunchBase More TechCrunch Europe TechCrunch France TechCrunch Japan Register - Login or Advanced Search Home > Products > Thunderbird ...

F-16C Thunderbirds Formation - Flickr - Photo Sharing!
USAF Thunderbirds at the 2008 Battle Creek Air Show

Thunderbirds Are Go - Introducing The World - YouTube
The world of Thunderbirds Are Go, Tracy Island, miniature sets and craft have been lovingly made by none other than WETA Workshop - the model ...

Thunderbirds are go: First pictures of TV remake
The first images of the upcoming TV reboot of the iconic series Thunderbirds have been released, recasting the iconic puppets from the 1960s ...

Thunderbirds creator Gerry Anderson dies aged 83
... puppet TV shows Captain Scarlet, Stingray and Joe 90 died in his sleep, his son announces. Gerry Anderson, best known as the creator of Thunderbirds ...

Firebirds hold nerve to hold out Thunderbirds
It was another close shave but Queensland Firebirds coach Roselee Jencke was happy for her side to take a second straight win.

Thunderbirds are go, puppets are gone
Human Thunderbirds? What does this mean, writes James Cockington. - The Age Online

Southerners steal last-gasp draw against Thunderbirds
Southern Steel stole a 53-53 draw in the chaotic final seconds of their trans-Tasman netball league clash against Adelaide Thunderbirds.

Resources last updated: 12/12/2015 2:36:37 PM