A Question About ThunderBird
Deadman
I am a graduate student in the Department of Information Systems at
the University of Maryland, Baltimore County (UMBC). I am doing
research in the area of software engineering. I would very much
appreciate if you could answer the following questions of mine:
1. I was wondering if ThunderBird has gone under any major
restructuring/redesign initiative in its history. Restructuring/
redesign initiative can be defined as a concerted effort during a time
period in which major changes were applied to the code base to improve
software architecture/design while little or no functional enhancement
was made.
2. If the project has gone under such an initiative, then would it be
possible for you to give the dates or revision/release numbers that
are "right before" and "right after" this structuring effort? I would
like to checkout the source code from the repository to compare
structural measurements that belong to "before" and "after" snapshots.
Note that the dates and revision/release numbers should be right
before and right after the initiative because I would like to be able
to isolate and observe the effects of this effort.
Your response will be very helpful in our research. Thank you very
much for your time in advance. I look forward to hearing from you
soon.
Regards,
Mohammed Aziz
P.S. This research is solely performed for academic purposes.
Joshua Cranmer
> 1. I was wondering if ThunderBird has gone under any major
> restructuring/redesign initiative in its history. Restructuring/
> redesign initiative can be defined as a concerted effort during a time
> period in which major changes were applied to the code base to improve
> software architecture/design while little or no functional enhancement
> was made.
In general, the process of getting changes completed in Thunderbird
generally implies that any major redesigns of Thunderbird architecture
come coupled with enhancements, generally either increased extensibility
or increased performance characteristics.
Within core Mozilla code, there have been major pushes to deprecate and
replace certain APIs (nsXPIDL(C)String, nsIPref (old preference
management), and nsIFileSpec are a few of those that I have seen
permeate cvs logs). I am woefully unqualified to say why these changes
were made, but I am willing to bet it was primarily for performance reasons.
The following is a roughly reverse chronological list of the major API
changes made in Thunderbird:
* The kill-RDF efforts. Portions of these landed at various times (and
some have yet to land). That said, some of these have greatly increased
flexibility, particularly the folder pane portion.
* The nsIAbCard refactoring. This was intended as a portion of a larger
address book rewrite API (a few more portions of which have also landed,
but none quite so far reaching as this part). The main purpose of this
was to make the card structure a lot more extensible.
Anything before this point is before my time working on Thunderbird, so
I can only give you the major stuff I've seen in CVS logs.
* Address book service interface refactoring. It seems that a few
interfaces were combined to form nsIAbManager. This happened before my
first acquaintance with address book code, so I don't entirely know the
rationale here.
* The nsIFolder/nsIMsgFolder merge.
* The "AB_OUTLINER_BRANCH." I don't know what was on this branch, but I
do know it was very large (the patch on the related bug seems to be 600 KB).
* The "mailnews performance branch." I'm told this was when the thread
pane moved from using RDF to using a custom tree view. At the very
least, this is credited with "Improvements in scrolling, folder loading,
message display, replyto time, sorting, selecting, deleting, the list
goes on and on."
Not to mention, of course, the architectural decision made eons ago to
move to C++ from C, or other major changes taken before the public
release of Mozilla code.
> 2. If the project has gone under such an initiative, then would it be
> possible for you to give the dates or revision/release numbers that
> are "right before" and "right after" this structuring effort? I would
> like to checkout the source code from the repository to compare
> structural measurements that belong to "before" and "after" snapshots.
> Note that the dates and revision/release numbers should be right
> before and right after the initiative because I would like to be able
> to isolate and observe the effects of this effort.
So, the first two major rewrites took place in the mercurial
comm-central repository.
The kill-RDF rewrites took place over a wide timeframe, so I can't say
"it landed at X timeframe".
<https://bugzilla.mozilla.org/show_bug.cgi?id=420506> has a list of the
bugs that were checked in as part of this effort.
The nsIAbCard rewrite (modulo some regression fixes) happened in
<http://hg.mozilla.org/comm-central/rev/b9967a04b9bd>.
The rest of them happened during the CVS era.
nsIAbManager creation: around 2007-12-13 to 2008-02-02 (cvs copy removes
timestamp history, so I can't say for certain)
nsIFolder deletion: 2003-11-11 to 2003-11-17 (at least three separate
checkins)
AB_OUTLINER_BRANCH: 2001-12-21
Mailnews performance branch: 2001-03-16
For many of our large changes, we tend to spread the changes out over
many patches, so a strict before/after comparison might not be generally
possible.
Robert Kaiser
> * The "AB_OUTLINER_BRANCH." I don't know what was on this branch, but I
> do know it was very large (the patch on the related bug seems to be 600
> KB).
"outliner" back then was the name of the new tree widget, the one that
is now <tree> (the old <tree> was more similar to the current <listbox>
and could host real XUL widgets in its cells). I guess that branch had
the rework of the UI to the new tree, or outliner, widget.
Robert Kaiser
Joshua Cranmer
I do see evidence of some IDL changes in the patch on the bug, but I'm
really not qualified to speak much on this subject. My archeology
knowledge is mostly related to news code and some of the nsMsg helpers.
David Bienvenu
The short answer is that we haven't really done a major restructuring/redesign without also doing functional enhancements, other than the kinds of things Joshua
described. Asuth did a fair amount of work restructuring some of the front end code in https://bugzilla.mozilla.org/show_bug.cgi?id=474701 but a lot of new functionality
(global search) was added at the same time.
- David
Andrew Sutherland
> than the kinds of things Joshua described. Asuth did a fair amount of
> work restructuring some of the front end code in
> https://bugzilla.mozilla.org/show_bug.cgi?id=474701 but a lot of new
> functionality (global search) was added at the same time.
Also, that was almost exclusively JavaScript 1.6+ code which is likely
to defy most existing automated analysis tools that do anything more
than simple syntactic analysis. (Even the mozilla tooling intended for
things like this like jcranmer's work on jshydra would need a lot of
hand-holding).
Andrew