From kde-core-devel  Sun Oct 01 09:15:57 2006
From: Simon Hausmann <hausmann () kde ! org>
Date: Sun, 01 Oct 2006 09:15:57 +0000
To: kde-core-devel
Subject: Re: [RFC] How to handle backends properly?
Message-Id: <200610011115.58470.hausmann () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=115969421030498
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart4167383.vquQYtrk9T"

--nextPart4167383.vquQYtrk9T
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 hosti=
ng
> 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 th=
is
> 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 t=
hat=20
distributors can enable/disable individual ones.

The main advantage of having them in kdelibs is convenience and the fact th=
at=20
you can keep the API private for a few releases, so that you can develop th=
e=20
interfaces, break source and binary compatibility, until you feel that=20
they're stable.

Simon

--nextPart4167383.vquQYtrk9T
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBFH4dOWXvMThJCpvIRApC5AJsHX0E6PuFp3ZhxzMtt5bNMkUtArQCfZ5ag
Ld+lUtgpj4Y0R7SN49e1UzE=
=SwBR
-----END PGP SIGNATURE-----

--nextPart4167383.vquQYtrk9T--