[RFC] How to handle backends properly?

[Simon Hausmann]

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
> backends.
>
> 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 
they're stable.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061001/c6aab797/attachment.sig>