From kde-core-devel  Mon Dec 18 19:57:07 2006
From: "Aaron J. Seigo" <aseigo () kde ! org>
Date: Mon, 18 Dec 2006 19:57:07 +0000
To: kde-core-devel
Subject: Re: Proposal: Integration of libKMetaData into kdelibs
Message-Id: <200612181257.07296.aseigo () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=116647184718526
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart2239669.4ig1NmQHPC"

--nextPart2239669.4ig1NmQHPC
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 18 December 2006 9:44, Sebastian Tr=C3=BCg wrote:
> last Friday I discussed the new libkmetadata with Aaron Seigo. We agreed
> that it would be a good idea to have it in kdelibs so all KDE applications
> could benefit from it.

the plan we discussed is something like this:

=2D put qrdf into kdesupport. it has no kde dependencies (only Qt) and stil=
l has=20
API work left to be done on it anyways.
=2D put kmetadata in kdelibs/ .. this would include (Sebastian: correct me =
if=20
i'm wrong here):
    - backbone
    - kmetadata
    - strigiindexer (optional component relying on strigi being installed)
    - tests
=2D move the example apps over time to appropriate places, e.g. extragear/s=
earch=20
or whatever

the goals are:

 - have a consumable API that ships with KDE 4.0
 - work on apps consuming that API for KDE 4.1

if the second goal is also hit for 4.0, great. but my recomendation is to s=
et=20
that as a 4.1 goal. i personally feel that's more realistic if the goal is =
to=20
include a broad set of applications. i assume a few, or even a good number,=
=20
of apps will use it in 4.0 but it'll really take off post-4.0. but for that=
=20
to happen, we need the API in a usable form in 4.0.

whether or not there'll be a BC gaurantee in 4.0 for it is something that's=
=20
left to discussion at this point, but in a Good World there would be. there=
's=20
still time enough for that, particularly if we get the API in sooner (e.g.=
=20
now) rather than later (e.g. N months from now) so we can kick its tires=20
thoroughly with our own applications.

the "why" is pretty simple: to give kde4 the ability to grow into a fully=20
searchable, fully linkable, fully semantic desktop. just like how network=20
awareness was a goal of kde 2.0 that become realized more and more over tim=
e=20
(years, actually), we can set a similar goal for search and semantics.

=2D-=20
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

=46ull time KDE developer sponsored by Trolltech (http://www.trolltech.com)

--nextPart2239669.4ig1NmQHPC
Content-Type: application/pgp-signature

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

iD8DBQBFhvKT1rcusafx20MRAmMjAKCoMZxEx3rcNY+7U+wz7lZsOg72aQCgk8Uc
JpjKa/MqerUwvzUnmNuZMp4=
=Hger
-----END PGP SIGNATURE-----

--nextPart2239669.4ig1NmQHPC--