Re: [Banshee-List] Proposal: Mono.Media
- From: "Scott Peterson" <lunchtimemama gmail com>
- To: banshee-list gnome org
- Subject: Re: [Banshee-List] Proposal: Mono.Media
- Date: Wed, 2 Jan 2008 05:16:58 -0600
Well while we're waiting for Aaron's feedback, why don't we start a preliminary dialogue. I think the first consideration is whether or not each backend will be its own assembly. There are pros and cons to each approach.
EACH BACKEND IS ITS OWN ASSEMBLY
Pros:
- Modularity. New backends can be added with ease.
- Size. If you know you're shipping on Linux, you can remove the Windows/Mac-specific backends.
- Backend autonomy. Each backend can be its own MonoDevelop project and its own package. Multiple people can maintain different backends and be well out of each other's way. Backends can even live in different svn repos.
Cons:
- Shipping multiple files. If Mono.Media.dll is the only deliverable, it is very easy for someone to drop it into their project and start using it. Things become trickier when there are many assemblies for many backends.
- "New backends can be dropped in and they will instantly work" doesn't strike me as a compelling use case. Banshee works like this and, to my knowledge, no new "drop-in" backends have ever been produced; if a new backend is written, it just ships with the next version.
ALL BACKENDS ARE INCLUDED IN THE ONE ASSEMBLY
Pros:
- Simple shipping. Mono.Media.dll is all you need.
- Consolidated development. All new backends must be integrated into the main Mono.Media project. This keeps everything centralized and organized.
Cons:
- Not modular. You can't just "drop in" new backends. Again, I wonder how often backends are likely to be "dropped in".
- Size. The assembly will contain the code for every backend, including those which are not applicable to a given system or application. Again, I wonder if this is a significant issue.
My personal preference is a hybrid of the two: all backends are part of a single assembly, but external backends will be loaded if they are present. This combines the modularity of the first option (which I believe is its strongest selling point) with the singularity of the second (which I believe is a powerful benefit). What do you think?
On Dec 30, 2007 9:35 PM, Gabriel Burt <
gabriel burt gmail com> wrote:
On Dec 18, 2007 3:19 PM, Scott Peterson <
lunchtimemama gmail com> wrote:
> Well if other people are interested in shaping the design of an API we could
> set up a wiki and begin some discussions, or if folks would rather start
> from actual code, someone could do a prototype library and we could go from
> there. I personally favor having actual code to talk about and I'd be happy
> to do a prototype API. But first, there is one voice I am eager to hear on
> this matter. Since Mono.Media would initially an abstraction of
> Banshee.MediaEngines, abock's opinion is key.
It definitely makes sense to me to encapsulate as much of this
reusable functionality in reusable libraries. A lot of the work being
done in trunk is to separate out non-Banshee-dependent bits better
(see Hyena/Hyena.Gui).
Seems like the Banshee.AudioProfiles code would belong in Mono.Media as well.
Aaron, what do you think? I can see we wouldn't want to let this slow
progress on trunk, but if we could figure out a design and Scott and
others could run with it?
Gabriel
--
Scott.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]