[RFC] How to handle backends properly?
hausmann at kde.org
Sun Oct 1 10:15:57 BST 2006
On Saturday 30. September 2006 17:08, Kevin Ottens wrote:
> Hello list,
> As you probably know, Solid finally entered kdelibs yesterday. It's the
> second library using a frontend/backend architecture[T]. And basically it
> raises the question on how do we want to manage the development of those
> Basically we have two kinds of backends:
> - Fake backends, stub providing simulated features
> - Backends actually providing real features
> Of course the fake backends are already hosted in kdelibs with the
> libraries to support the development and allow to unit test the libraries.
> So the question is more about where to host the other ones?
> Currently backends for Phonon are hosted in kdemultimedia[M] which looks
> like the right place to do this. For Solid the situation is less clear,
> should it be in kdebase/runtime[R]?
> At first that looks like a sensible choice. The problem I have with hosting
> those backends in kdebase or kdemultimedia is that we loose a property of
> this splitting (at least in the way they'll be perceived by distributors):
> decoupled release cycles.
> One of the point of those backends is to be able to make a release when a
> subsystem see its behavior changing (like in the transition from HAL 0.4 to
> 0.5 for instance). Hosting them in kdebase or kdemultimedia doesn't really
> support this idea.
> So, I'm wondering if it would be a good idea to create a specific module
> for those backends. With specific release rules. I think it should be
> released each time we release kdelibs, but extra development and releases
> would be allowed when one of the backends is broken because of a behavior
> change in one of the subsystems. It would be more convenient to manage this
> way. Also, having the backends in a separate module would give a clear
> signal to distributors that they can choose only the few ones they want to
> support for their distribution without too much headache.
> Any opinions? More food for thought in this area?
I suggest to put them all into kdelibs, perhaps with configure options so that
distributors can enable/disable individual ones.
The main advantage of having them in kdelibs is convenience and the fact that
you can keep the API private for a few releases, so that you can develop the
interfaces, break source and binary compatibility, until you feel that
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel