Thunderbird/Students/StatusUpdates/2010-03-12: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 6: Line 6:


===== Tim Miller  =====
===== Tim Miller  =====
This week was spring break. I worked a lot at my 2 jobs, so the only real break I got was that I didn't do homework that I probably should have, including this.


===== Marcel Guzman  =====
===== Marcel Guzman  =====

Revision as of 13:58, 16 March 2010

This week’s Random Notes

Status Updates

Zach Church
Tim Miller

This week was spring break. I worked a lot at my 2 jobs, so the only real break I got was that I didn't do homework that I probably should have, including this.

Marcel Guzman
Kefu Zhao

I am sorry that I didn't update my status last week and I will summarize my work here for both last week and this week.

Basically, I was still trying to find a way to parse the "delivered-to" headers last week. After talking to several people (big thanks to asuth) on irc, I realized that I was on a wrong direction by trying to use mimeHeader->extractHeader() function call. As a result, this week I tried to add my "delivered-to" headers into currentHeaderData[] array when a mail is first parsed. Then, I was able to use currentHeaderData for deciding the "from" address in "reply to list".

Actually, there are four ways to decide the "From" address:

1. check only for delivered-to headers con: not every mail server will add "delivered-to" headers

2. check the folder in which a mail is located and use that folder information to get the correct identity con: not working for a saved mail. For example, if a user save the a mail as .eml file and open it again, there will b eno folder information.

3. check the "received" headers con: there are a vast amount of "received" headers which are not relevent.

4. convince Mailman con: need to convince another team

So after working for 3 days in a row this week, I implemented the first two approach. Now I am writing tests for my patch and hopefully I can deliver it this weekend.

Lindauson Hazell
Evan Stratford
Wei Xian Woo

This week I identified what needs to be persisted in order to restore the state of a message window, which is pretty much the same information we already persist for a "message in a tab". (The message window and message tab are separate components of the app. A message window is a StandaloneMessageDisplayWidget.)

I then started implementing the |getState| function for the message window. Next step is to implement the |restoreState| function and make a few minor adjustments to the session store manager to support this window type.

Who’s writing the blog post this week?

Zach Church