[fluid-dev] FS2.0 proposal

[Bernat Arlandis i Mañó]

Hi.

Sorry for the long wait but I'm a bit busy lately. This is how it's 
gonna be since this is something I have to do on my spare time so there 
will be ups and lows inevitably, but I'm firmly decide to get there with 
your help.

I've been thinking a bit on what I'd like to do for FS2.0 and would be 
interesting to do. My goal is having a better code base to work on 
building new features and improving performance and compatibility 
without the problems we have right now.

My first priority is designing a simple API that hides the internals and 
provides just what is needed and expected from FS. I think this is also 
the first thing that should get done since it's fundamental to other 
decisions, the new API will guide the refactoring of the code.

I've made a simple design diagram for FS components (image attached), 
dependencies have been minimized and there's no loops. Based on this 
diagram we should be able to define what every component should provide 
and what not. Every component should be seen as a library even though 
we're not planning on distributing them separated, thus every component 
will have its own API and the sum of them will be the FS API.

We must follow some guidelines to library implementation as suggested by 
Max Kellermann. All API functions should check their parameters and 
report their condition by returning result codes. Abnormal conditions in 
internal functions can be taken care by asserts and should be treated as 
programming errors.

We should also remove code from FS that can be used from external 
libraries. We talked about using glib and the swami sounfont library, 
maybe using gobject too. I took a look at gobject and I think it might 
be overkill for this project right now.

We'll be breaking compatibility in a major way, so another important 
task is helping applications become compatible with the new API by 
providing patches and support. We could try providing a compatibility 
layer for the old API but it might take too much effort.

So, this is a list of tasks without strict order:

- Define API for every component.
- Replace code with external libraries where possible.
- Refactor code.
- Implement missing API functions.
- Implement checks and result codes on every API function.
- Document the new API.
- Helping applications developers upgrade to the new API.

This is much work, and we're a just few developers with not much time. I 
won't mind working alone, but there's some subjects where I'd truly need 
your help:

- Autotools/automake/libtool maintenance and support.
- Platform building and testing (including drivers).

Also, I'd like to avoid regressions, so everyone willing to test every 
new commit and report feedback is very welcome. Providing patches for 
maintaining compatibility with other applications (like QSynth) would 
help doing better testing too.

There's some places where collaboration will be necessary (API design), 
but sometimes it'll be troublesome (refactoring), communication will be 
really important. I'd like this to be a collaborative effort and get you 
all involved in some way, but coordination and direction is very 
important to succeed so I should take the lead in this branch.

As can be seen, implementing new features is not the main goal right 
now, but if we get the new modular design right then some wanted 
features will get done without effort. Besides, anyone can start a new 
branch if they feel like implementing any experimental feature, if it's 
good it can be merged later.

I'd start by posting a simplified draft of the current API so we can 
start discussing, but I'd like to read first your comments about this. 
How do you think you could get involved... what's wrong... whatever you 
think is important.

Regards.

--
Bernat Arlandis i Mañó