Re: [Banshee-List] Looking for some information about the Banshee architecture

[Bertrand Lorentz <bertrand lorentz gmail com>]

Hi,

Sorry it took so long to reply. I hope the answers below will still be useful.
Disclaimer: I'm not the best person to answer your questions, as I was
not involved when most of the current design was created by Aaron and
Gabriel. So I'm doing some second-guessing here...


On Tue, Jan 17, 2012 at 11:04 AM, S.E.Heitmeijer
<s e heitmeijer student rug nl> wrote:
> Hello everybody,
>
> As was explained a little bit in the previous email (by Frank Blauw), we are
> interested in the design patterns that are used by Banshee and the reasons
> behind choosing those patterns. 'gnomeuser' already has been so kind to help
> us out with these questions but suggested to also send them to the mailing
> list because there would be people that could give a more fulfilling answer.
> So please take a look at the questions below, it would be a big help.
>
>   By looking at some of the documentation and related posts, such as this
> post by Aaron Bockover, it becomes clear that Banshee is more than just a
> program and is implemented to be a platform which can be used by developers.
> Were there any concrete choices made on structuring Banshee according to a
> specific known architectural pattern, e.g. the post by Aaron shows a figure
> with separated multiple layers, or is its structure something that just
> “randomly” developed overtime? It seems to us that most of the code is very
> thought out and object oriented which suggests that development is very
> structured and that choices for patterns are deliberately made. The
> extensions seem particularly challenging and most system use one of the
> known patterns for such constructions. Could you name some of the patterns
> that were picked or simply exist in Banshee?

I think a lot of the current architecture emerged during the big
refactoring that happened in 2007/2008. It evolved from the codebase
of the 0.x series, learning from that experience. A good way to design
a good framework or platform is to be a user of that framework, so
being able to go back and forth between Banshee-the-app and
Banshee-the-framework had probably helped.
I can think of a few principles that have driven the architecture design:
- Separation of UI code and non-UI code
- Separation of the platform/OS specific code
- Distinction between the parts that could be potentially useful for
others and the "Banshee only" parts.

The extension infrastructure comes mostly from Mono.Addins [1]. Other
than an extensive use of interfaces and some singletons, there are no
other specific design patterns that comes to my mind. There are
probably some used, but I'd have to dig through the code to find them.
I guess you could do that as well as me ;)

[1] http://www.mono-project.com/Mono.Addins

>   If any patterns were picked then it’s usually for a specific reason or
> goal. What are the quality attributes that are kept in mind when
> changing/upgrading Banshee’s features? For example, is it more important
> that Banshee is adaptable through plugins/extensions than the code's
> maintainability or is performance more important than the accessibility of
> the software on other systems? What would you say are currently the three
> most important quality attributes (the key drivers)  for Banshee?

I think adaptability and maintainability go hand in hand. In order for
Banshee to be adaptable through extensions, it has to be very modular,
with as low coupling as possible between each module. And this helps a
lot with maintenance. And then, this modularity then helps you solve
the performance versus portability problem.

For example, our file I/O is done with pluggable backends, each
backend is a Mono.Addins extension and implements a set of interfaces
in the Banshee.IO namespace. I tihnk the original reason for that is
the fact that the standard .Net API (System.IO), which is available on
all platform, performs poorly on Linux. So on Linux we were using the
Mono.Unix API instead, while still being able to fallback to System.IO
when necessary. And then later on, we wanted to use the GIO API [2] on
Linux, so we just had to implement an additional backend, without
having to change anything in the core of Banshee.

For me, the top 3 quality attributes would be: maintainability,
reliability and performance. But it's always a balancing act.

[2] http://developer.gnome.org/gio/stable/

>   Since Banshee is open source software it’s ultimately up to developers to
> fulfill Banshee’s course for the future but there are also other parties
> involved such as Novell and the Gnome foundation. We were wondering if such
> contributors determine most of Banshee’s course? Are Aaron Bockover,
> Alexander Kojevnikov, Bertrand Lorentz, and Gabriel Burt the driving force
> behind the overall course of Banshee? Or is this all simply determined and
> agreed upon by its community?

The GNOME Foundation does have any direct power on the technical
things in the GNOME project in general, or in Banshee in particular. I
think the fact that Aaron and Gabriel were employed by Novell and able
to spend time working on Banshee had a significant impact, as it
allowed them to do the big refactoring in 2007/2008. This gave us a
lot of the architecture we're enjoying now.

As a maintainer, I see myself as more of a gatekeeper than a driving
force. Most of the recent features were contributed by other people, I
just try to make sure those contributions meet the quality we need.
Sometimes, I might point to some general direction, for example by
updating a roadmap [3]. But in the end it's a do-ocracy : things only
go forward if somebody gets it done.

[3] https://live.gnome.org/Banshee/Roadmap

>   The purpose of the information as provided by you, and that what we
> extract from the documentation online, is to analyze the used patterns
> related to the key drivers of Banshee. We want to find out if the patterns
> used comply with those key drivers or if they actually hinder the
> realization of those attributes. All of which has to be documented and
> evaluated in a report for our Software Patterns/Software Architecture
> course. Thank you again for helping us out.

Feel free to ask any other questions you might have, I'll try to reply
faster next ime ;)

-- 
Bertrand Lorentz