Thunderbird/Students/StatusUpdates/2010-03-12: Difference between revisions
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