Quantcast

Mozilla Thunderbird Software Design Practices

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Mozilla Thunderbird Software Design Practices

Daniel José Barbeira Hayes
Hello,

My name is Daniel Barbeira Hayes and i'm a student of the masters degree in computer engineering at the Universidad de Coruña.

I'm doing an academic project that involves studying and analyzing the software design of an open source project, and for my case study, I chose Mozilla Thunderbird.
I use Thunderbird on a daily basis, and I consider it a great tool and it really helps boost my productivity saving me huge amounts of time managing my email.

Related to the case study, I would be interested if you could give me some inside information on the following points:

- Development methodology followed, and tools used such as for communications, operating system used, etc.

- Software Architecture: patterns and anti-patterns. I'm interested in knowing if you follow any well known architectural patterns such as client-proxy server, a layered architecture, replicated servers, model view controller, etc. It would be also interesting to know if you have detected any anti-patterns related to your architecture too.
Examples of architecture antipatterns are autogenerated stovepipe, Jumble, vendor lock-in, design by comittee or reinventing the wheel.

- Software design: design patterns and anti-patterns. Analyzing your source code which I obtained from the repository http://hg.mozilla.org/comm-central, I haven't really being able to see if you follow many patterns or not. I know that most of the source code is written in C++, and I would like to know if you have followed an object oriented design or not, and if you have applied well known patterns such as facades, abstract factories, builders, observers, composites etc. I would also be interested in knowing if you have detected any anti-patterns related to your SW design.
Examples of antipatterns are Blob classes, continuous obsolesence, spaghetti code, cut and paste programming, etc.

Any documentation or references that you could provide would be of a huge help also.

Many thanks and kind regards,
Daniel.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mozilla Thunderbird Software Design Practices

gNeandr-12
Maybe it's a good idea to join this group:
tb-planning <[hidden email]>
to post your request there and to get attention of the many Thunderbird
dev people.

That group is moderated and to receive all posting you should join:
https://mail.mozilla.org/listinfo/tb-planning



On 12.01.2017 18:46, Daniel José Barbeira Hayes wrote:

> Hello,
>
> My name is Daniel Barbeira Hayes and i'm a student of the masters degree in computer engineering at the Universidad de Coruña.
>
> I'm doing an academic project that involves studying and analyzing the software design of an open source project, and for my case study, I chose Mozilla Thunderbird.
> I use Thunderbird on a daily basis, and I consider it a great tool and it really helps boost my productivity saving me huge amounts of time managing my email.
>
> Related to the case study, I would be interested if you could give me some inside information on the following points:
>
> - Development methodology followed, and tools used such as for communications, operating system used, etc.
>
> - Software Architecture: patterns and anti-patterns. I'm interested in knowing if you follow any well known architectural patterns such as client-proxy server, a layered architecture, replicated servers, model view controller, etc. It would be also interesting to know if you have detected any anti-patterns related to your architecture too.
> Examples of architecture antipatterns are autogenerated stovepipe, Jumble, vendor lock-in, design by comittee or reinventing the wheel.
>
> - Software design: design patterns and anti-patterns. Analyzing your source code which I obtained from the repository http://hg.mozilla.org/comm-central, I haven't really being able to see if you follow many patterns or not. I know that most of the source code is written in C++, and I would like to know if you have followed an object oriented design or not, and if you have applied well known patterns such as facades, abstract factories, builders, observers, composites etc. I would also be interested in knowing if you have detected any anti-patterns related to your SW design.
> Examples of antipatterns are Blob classes, continuous obsolesence, spaghetti code, cut and paste programming, etc.
>
> Any documentation or references that you could provide would be of a huge help also.
>
> Many thanks and kind regards,
> Daniel.
>

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mozilla Thunderbird Software Design Practices

Daniel José Barbeira Hayes
Hi,

Thanks for the answer. I previously contacted with the mailing list you are indicating me, and from there the moderator recommended me to direct my query to the dev-apps mailing list, since my questions are more
of a technical nature.

Could anyone help me out or redirect me to some group or person who could give me the info i need?
Any links related to documentation related would be helpful also.

Many thanks and kind regards,
Daniel.

----- Mensaje original -----
De: "gNeandr" <[hidden email]>
Para: [hidden email]
Enviados: Sábado, 14 de Enero 2017 13:03:09
Asunto: Re: Mozilla Thunderbird Software Design Practices

Maybe it's a good idea to join this group:
tb-planning <[hidden email]>
to post your request there and to get attention of the many Thunderbird
dev people.

That group is moderated and to receive all posting you should join:
https://mail.mozilla.org/listinfo/tb-planning



On 12.01.2017 18:46, Daniel José Barbeira Hayes wrote:

> Hello,
>
> My name is Daniel Barbeira Hayes and i'm a student of the masters degree in computer engineering at the Universidad de Coruña.
>
> I'm doing an academic project that involves studying and analyzing the software design of an open source project, and for my case study, I chose Mozilla Thunderbird.
> I use Thunderbird on a daily basis, and I consider it a great tool and it really helps boost my productivity saving me huge amounts of time managing my email.
>
> Related to the case study, I would be interested if you could give me some inside information on the following points:
>
> - Development methodology followed, and tools used such as for communications, operating system used, etc.
>
> - Software Architecture: patterns and anti-patterns. I'm interested in knowing if you follow any well known architectural patterns such as client-proxy server, a layered architecture, replicated servers, model view controller, etc. It would be also interesting to know if you have detected any anti-patterns related to your architecture too.
> Examples of architecture antipatterns are autogenerated stovepipe, Jumble, vendor lock-in, design by comittee or reinventing the wheel.
>
> - Software design: design patterns and anti-patterns. Analyzing your source code which I obtained from the repository http://hg.mozilla.org/comm-central, I haven't really being able to see if you follow many patterns or not. I know that most of the source code is written in C++, and I would like to know if you have followed an object oriented design or not, and if you have applied well known patterns such as facades, abstract factories, builders, observers, composites etc. I would also be interested in knowing if you have detected any anti-patterns related to your SW design.
> Examples of antipatterns are Blob classes, continuous obsolesence, spaghetti code, cut and paste programming, etc.
>
> Any documentation or references that you could provide would be of a huge help also.
>
> Many thanks and kind regards,
> Daniel.
>

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mozilla Thunderbird Software Design Practices

Jörg Knobloch
In reply to this post by Daniel José Barbeira Hayes
As a relative newcomer to Thunderbird development, let me give you some
answers here.

On 12/01/2017 18:46, Daniel José Barbeira Hayes wrote:
> - Development methodology followed, and tools used such as for communications, operating system used, etc.
First you have to understand the history of Thunderbird and Firefox.
Both were born out of Netscape Navigator about 10 years ago. The browser
part and core libraries are maintained by a big team of paid employees
of Mozilla and volunteer contributors. Thunderbird is maintained by a
small team of volunteers, although as of the end of 2016 the project
employs a maintainer who looks after "continuous integration" with the
ever-changing Mozilla core platform and after releases.

Mozilla software is a mix of JS, C++, XUL and other technologies,
perhaps most importantly Rust. It executes on Windows, Mac and Linux.
Developers communicate via IRC or e-mail (lists), however, Bugzilla is
the most important medium of communication. Mozilla employs a hole host
of open source tools, for example Mercurial for the source code
repository and  Buildbot, Taskcluster and Python for the build
infrastructure. Mozilla also gives funds to the open source community,
check https://wiki.mozilla.org/MOSS.

> - Software Architecture: patterns and anti-patterns. I'm interested in knowing if you follow any well known architectural patterns such as client-proxy server, a layered architecture, replicated servers, model view controller, etc. It would be also interesting to know if you have detected any anti-patterns related to your architecture too.
> Examples of architecture antipatterns are autogenerated stovepipe, Jumble, vendor lock-in, design by comittee or reinventing the wheel.
I'm not sure what to write here. Thunderbird is of course an e-mail
client. And of course the software is organised in layers.

> - Software design: design patterns and anti-patterns. Analyzing your source code which I obtained from the repositoryhttp://hg.mozilla.org/comm-central, I haven't really being able to see if you follow many patterns or not. I know that most of the source code is written in C++, and I would like to know if you have followed an object oriented design or not, and if you have applied well known patterns such as facades, abstract factories, builders, observers, composites etc. I would also be interested in knowing if you have detected any anti-patterns related to your SW design.
> Examples of antipatterns are Blob classes, continuous obsolesence, spaghetti code, cut and paste programming, etc.
Yes, you can browse the Thunderbird code at
http://hg.mozilla.org/comm-central but there is also
https://dxr.mozilla.org/comm-central/source/. I don't know about the
ratio JS to C++, but there is a large part written in JS. Mozilla
employs some very fine developers, so of course all the relevant design
techniques are used were appropriate. Mozilla is constantly renewing its
core libraries. The C++ part of Thunderbird follows object oriented
design (how could not not?).

As a humble Thunderbird contributors I'm not familiar with most of the
anti-patterns you mentioned. Of course, especially in Thunderbird, we
have some legacy code, and of course some parts of the software were
created by cut and paste, but I'm not familiar with the exact
definitions of "spaghetti code" or "cut and paste programming".

You can study the code yourself, it's open source.

Jörg K.


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mozilla Thunderbird Software Design Practices

Philipp Kewisch-2
In reply to this post by Daniel José Barbeira Hayes
On 1/14/17 6:47 PM, Jörg Knobloch wrote:
> I don't know about the ratio JS to C++, but there is a large part
> written in JS.

Just wanted to answer to this specific aspect, you might want to check
out https://www.openhub.net/p/thunderbird which shows some data from 6
months ago. As the codebase also includes a repository shared with
Firefox, this may not be 100% accurate, but it gives you an idea.

I wish you all the best in studying Thunderbird. We would be delighted
to hear about your results!

Thanks,
Philipp
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mozilla Thunderbird Software Design Practices

Joshua Cranmer 🐧
In reply to this post by Daniel José Barbeira Hayes
On 1/12/2017 11:46 AM, Daniel José Barbeira Hayes wrote:

> Hello,
>
> My name is Daniel Barbeira Hayes and i'm a student of the masters degree in computer engineering at the Universidad de Coruña.
>
> I'm doing an academic project that involves studying and analyzing the software design of an open source project, and for my case study, I chose Mozilla Thunderbird.
> I use Thunderbird on a daily basis, and I consider it a great tool and it really helps boost my productivity saving me huge amounts of time managing my email.
>
> Related to the case study, I would be interested if you could give me some inside information on the following points:
>
> - Development methodology followed, and tools used such as for communications, operating system used, etc.

As an open-source project, Thunderbird contributors can pretty much use
(and do use) whatever they want. It's like herding cats, or perhaps
wrangling lizards. :-)
>
> - Software Architecture: patterns and anti-patterns. I'm interested in knowing if you follow any well known architectural patterns such as client-proxy server, a layered architecture, replicated servers, model view controller, etc. It would be also interesting to know if you have detected any anti-patterns related to your architecture too.
> Examples of architecture antipatterns are autogenerated stovepipe, Jumble, vendor lock-in, design by comittee or reinventing the wheel.
>
> - Software design: design patterns and anti-patterns. Analyzing your source code which I obtained from the repository http://hg.mozilla.org/comm-central, I haven't really being able to see if you follow many patterns or not. I know that most of the source code is written in C++, and I would like to know if you have followed an object oriented design or not, and if you have applied well known patterns such as facades, abstract factories, builders, observers, composites etc. I would also be interested in knowing if you have detected any anti-patterns related to your SW design.
> Examples of antipatterns are Blob classes, continuous obsolesence, spaghetti code, cut and paste programming, etc.

I rather suspect most contributors don't explicitly think in terms of
design patterns or anti-patterns. I certainly don't look at a patch and
go "you're wrong, you should have used a Flyweight pattern here" (I
actually don't know what the flyweight pattern is, it's just the example
I go to for design pattern terminology). That doesn't mean that we don't
use them--most design patterns, quite frankly, are basically common
sense design that could be arrived at without having to know them
explicitly.

Some things to understand. First, a large portion of Thunderbird dates
back essentially to NS6, and there is clearly missing history that
predates even the CVS 1.1 dates in 1999-2001. Some of the code even goes
back to NS5 and earlier--which is to say, it was originally written in C
and carried over with minimal changes (there's a date in a libmime
comment in 1997, and the structure of nsMsgSend and friends at times
clearly belie a C heritage). This age means that some code straddles
several eras of design, and given the usual desire for minimizing
changes when adding new features, that usually means you get jarring
borders between them (again, some of the compose code is a veritable
mess in this regard).

Another point is that mail infrastructure is, to a first approximation,
mature. The core design would have been made about 2 decades ago, and
there's not really been any sufficiently major changes in protocols to
warrant rethinking that design (the last such major protocol change I
can think of is MIME, a quarter of century ago, unless IMAP UID is
actually newer than MIME)--contrast this to the world of HTML layout,
and the various overhauls that HTTP has undergone. Given that the
original developers have all since left the project, this means that
there's a core design whose historical documentation is lacking with 20
years of accretions on top of that.

Now are there antipatterns in some form? Most definitely. In general, we
struggle from too-tight coupling of code--I recall when I made that
patch to separate delete and cancel for news accounts that I had to
change a dozen or so places of "if this account is news, do not allow
delete." There is also an endemic problem of resorting to punching extra
holes in interfaces instead of thinking about how the API can be
redesigned--consider the issue of name, prettyName, prettiestName,
abbreviatedName on nsIMsgFolder. We've also suffered some abuses of API:
nsISubscribableServer is really an interface that's used in two
different ways at two different levels, and the MIME decoder gets
invoked in mostly the same way to mean completely different things.
There's also some times where we reimplement something because we can't
figure out how to use what exists--MIME decoding is again a wonderful
example of that, although nsIMsgAttachment, nsIMsgAttachedFile,
nsIMsgAttachmentData, and nsIMsgEmbeddedImageData certainly seem to be
trying for a world record for most redundant interfaces. And then
there's compose, which is more or less a fractal of bad design. I could
summarize nsMsgSend as "you call HackAttachments, you get out at
GatherMimeAttachments, and how you went from one to the other no one
really knows."

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mozilla Thunderbird Software Design Practices

Daniel José Barbeira Hayes
To all, thanks for the answers!! They're really helpful for the case study.

So far, from what I've been able to see and through your info, i'm going to orient the study of the software architectura as a client-server architectura (as Thunderbird is an email client), and i will also investigate on the mentioned layered architecture you follow.

As for the software design, i will observe the object oriented design followed in the parts made in C++. I have found some observer classes and some proxy classes, so i will continue investigating.

Another point I'm also interested in is related to the testing in the project for software quality and validation. I know you use BugZilla for bug tracking, and I've seen references to the use of MozTrap to manage test-cases. Apart from the use of Tinderbox for continuous integration, I would be interested in knowing if you follow any testing methodology, white and black box testing, and if you use any testing frameworks/suites for C++ or for Javascript.

One last point would be refering to the accesibility in your project. I've seen that Thunderbird incorporates some accesibility options, especially refering to the font size and colour, and i've also tried the folowing add-on related to accesibility: https://addons.mozilla.org/es/thunderbird/addon/theme-font-size-changer/
I'm planning on trying a screen reader like Orca on Thunderbird https://wiki.gnome.org/Projects/Orca , but i would also like to know if you have explicity worked and designed on solutions thinking exclusively about accesibility.

Many thanks and kind regards,
Daniel.


----- Mensaje original -----
De: "Joshua Cranmer 🐧" <[hidden email]>
Para: [hidden email]
Enviados: Domingo, 15 de Enero 2017 5:51:33
Asunto: Re: Mozilla Thunderbird Software Design Practices

On 1/12/2017 11:46 AM, Daniel José Barbeira Hayes wrote:

> Hello,
>
> My name is Daniel Barbeira Hayes and i'm a student of the masters degree in computer engineering at the Universidad de Coruña.
>
> I'm doing an academic project that involves studying and analyzing the software design of an open source project, and for my case study, I chose Mozilla Thunderbird.
> I use Thunderbird on a daily basis, and I consider it a great tool and it really helps boost my productivity saving me huge amounts of time managing my email.
>
> Related to the case study, I would be interested if you could give me some inside information on the following points:
>
> - Development methodology followed, and tools used such as for communications, operating system used, etc.

As an open-source project, Thunderbird contributors can pretty much use
(and do use) whatever they want. It's like herding cats, or perhaps
wrangling lizards. :-)
>
> - Software Architecture: patterns and anti-patterns. I'm interested in knowing if you follow any well known architectural patterns such as client-proxy server, a layered architecture, replicated servers, model view controller, etc. It would be also interesting to know if you have detected any anti-patterns related to your architecture too.
> Examples of architecture antipatterns are autogenerated stovepipe, Jumble, vendor lock-in, design by comittee or reinventing the wheel.
>
> - Software design: design patterns and anti-patterns. Analyzing your source code which I obtained from the repository http://hg.mozilla.org/comm-central, I haven't really being able to see if you follow many patterns or not. I know that most of the source code is written in C++, and I would like to know if you have followed an object oriented design or not, and if you have applied well known patterns such as facades, abstract factories, builders, observers, composites etc. I would also be interested in knowing if you have detected any anti-patterns related to your SW design.
> Examples of antipatterns are Blob classes, continuous obsolesence, spaghetti code, cut and paste programming, etc.

I rather suspect most contributors don't explicitly think in terms of
design patterns or anti-patterns. I certainly don't look at a patch and
go "you're wrong, you should have used a Flyweight pattern here" (I
actually don't know what the flyweight pattern is, it's just the example
I go to for design pattern terminology). That doesn't mean that we don't
use them--most design patterns, quite frankly, are basically common
sense design that could be arrived at without having to know them
explicitly.

Some things to understand. First, a large portion of Thunderbird dates
back essentially to NS6, and there is clearly missing history that
predates even the CVS 1.1 dates in 1999-2001. Some of the code even goes
back to NS5 and earlier--which is to say, it was originally written in C
and carried over with minimal changes (there's a date in a libmime
comment in 1997, and the structure of nsMsgSend and friends at times
clearly belie a C heritage). This age means that some code straddles
several eras of design, and given the usual desire for minimizing
changes when adding new features, that usually means you get jarring
borders between them (again, some of the compose code is a veritable
mess in this regard).

Another point is that mail infrastructure is, to a first approximation,
mature. The core design would have been made about 2 decades ago, and
there's not really been any sufficiently major changes in protocols to
warrant rethinking that design (the last such major protocol change I
can think of is MIME, a quarter of century ago, unless IMAP UID is
actually newer than MIME)--contrast this to the world of HTML layout,
and the various overhauls that HTTP has undergone. Given that the
original developers have all since left the project, this means that
there's a core design whose historical documentation is lacking with 20
years of accretions on top of that.

Now are there antipatterns in some form? Most definitely. In general, we
struggle from too-tight coupling of code--I recall when I made that
patch to separate delete and cancel for news accounts that I had to
change a dozen or so places of "if this account is news, do not allow
delete." There is also an endemic problem of resorting to punching extra
holes in interfaces instead of thinking about how the API can be
redesigned--consider the issue of name, prettyName, prettiestName,
abbreviatedName on nsIMsgFolder. We've also suffered some abuses of API:
nsISubscribableServer is really an interface that's used in two
different ways at two different levels, and the MIME decoder gets
invoked in mostly the same way to mean completely different things.
There's also some times where we reimplement something because we can't
figure out how to use what exists--MIME decoding is again a wonderful
example of that, although nsIMsgAttachment, nsIMsgAttachedFile,
nsIMsgAttachmentData, and nsIMsgEmbeddedImageData certainly seem to be
trying for a world record for most redundant interfaces. And then
there's compose, which is more or less a fractal of bad design. I could
summarize nsMsgSend as "you call HackAttachments, you get out at
GatherMimeAttachments, and how you went from one to the other no one
really knows."

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Mozilla Thunderbird Software Design Practices

Jörg Knobloch
On 15/01/2017 13:55, Daniel José Barbeira Hayes wrote:
> As for the software design, i will observe the object oriented design followed in the parts made in C++. I have found some observer classes and some proxy classes, so i will continue investigating.
One aspect of object oriented design is deriving classes from other
classes. We do that a whole lot. For example, Mozilla core has a generic
nsIURI class from which they derive nsIURL, and we use this class to
derive our special "mail URL" which lets us address messages, see
nsIMsgMailNewsUrl.idl.

Another important example are the two storage formats we support:
Berkeley mailbox and maildir. Again, both classes nsMsgBrkMBoxStore and
nsMsgMaildirStore are derived from a common super-class
nsIMsgPluggableStore. Our protocol classes nsNNTPProtocol,
nsMailboxProtocol, nsPop3Protocol are all derived from nsMsgProtocol.

> Another point I'm also interested in is related to the testing in the project for software quality and validation. I know you use BugZilla for bug tracking, and I've seen references to the use of MozTrap to manage test-cases. Apart from the use of Tinderbox for continuous integration, I would be interested in knowing if you follow any testing methodology, white and black box testing, and if you use any testing frameworks/suites for C++ or for Javascript.
To my knowledge we don't follow any specific testing methodology, but
any executable, be it developer, alpha, beta or release runs through an
extensive series of tests. Thunderbird uses Xpcshell test, which test
internal interfaces (white box test), and Mozmill tests (more like a
black box test), which simulate a user using using the product. For most
bugs we fix, we add tests, so the problem fixed won't regress later on.

You should really used DXR to explore the code base, for example:
https://dxr.mozilla.org/comm-central/search?q=file%3Atest&redirect=false

Let me add an anecdote: Some of our volunteers do bug triaging on BMO.
When we see a bug like "cannot send message", we can tell with 99.5%
security that this is an invalid bug caused by some misconfiguration,
add-on problem, ISP problem, etc., but not a bug in Thunderbird. Why?
Well, we test sending messages in our test suite and nothing will ever
ship where functions covered by tests, and an awful lot is covered,
don't work.

Jörg K.


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Loading...