From kde-core-devel  Mon Mar 12 21:37:59 2007
From: "Aaron J. Seigo" <aseigo () kde ! org>
Date: Mon, 12 Mar 2007 21:37:59 +0000
To: kde-core-devel
Subject: Re: Proposal: move libKMetaData (aka Nepomuk-KDE) into kdelibs
Message-Id: <200703121538.00309.aseigo () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117391277027966
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart3006943.z2pvNPyEl7"

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

On March 12, 2007, Sebastian Tr=C3=BCg wrote:
> it took way longer than I hoped but finally KMetaData has reached a state
> that allows a move to the kdelibs.

personally, i appreciate that you took the time it needed.

> There is still some work to be done and=20
> not everything is final but I think it is time that more people have a lo=
ok
> at it and find weaknesses through usage.

i agree that it should be moved to kdesupport and kdelibs as you noted, and=
=20
that the Next Steps you outlined make a good amount of sense.

some comments on the API:

kmetadata/datetime.h. it's really just a namespace rather than a class, no?=
=20
would it make sense to merge the parsing functionality into KDateTime=20
(kdelibs/kdecore/data/kdatetime.h)? in fact, does KDateTime::fromString wit=
h=20
TimeFormat ISODate already do what you need? (ditto for toString)

would you be adverse to switching the code style to the kdelibs style[1]?

why are there public data members (even though they are static and const) i=
n=20
ontology.h? would an accessor in the implementation that returns a string=20
literal be enough?

are the OTHERCLASSES and METHODS special flags in resource.h perhaps a bit=
=20
generic? could they be given names that are more explanatory or is that out=
=20
of your hands? either way a bit of a comment before each of them might make=
=20
it easier for those who come after to understand why they are there?

is the rcgen app meant to be installed? if so, perhaps it should have a les=
s=20
generic name as well?

i'd also recommend not providing a BC guarantee in 4.0 for this new set of=
=20
APIs so we have the opporutnity to fix problems if they arise for 4.1.

[1] http://techbase.kde.org/Policies/Kdelibs_Coding_Style

=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)

--nextPart3006943.z2pvNPyEl7
Content-Type: application/pgp-signature

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

iD8DBQBF9cg41rcusafx20MRAhsHAJ9beTFiZETqRuingui7bZ9FSfVM2gCfV8Qt
PmmqWiVAeOT9+TM1EwNx3wI=
=bKYx
-----END PGP SIGNATURE-----

--nextPart3006943.z2pvNPyEl7--