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ñó
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
