Proposal: move libKMetaData (aka Nepomuk-KDE) into kdelibs

[Sebastian Trüg]

On Monday 12 March 2007 22:37:59 Aaron J. Seigo wrote:
> some comments on the API:
>
> kmetadata/datetime.h. it's really just a namespace rather than a class, no?
> would it make sense to merge the parsing functionality into KDateTime
> (kdelibs/kdecore/data/kdatetime.h)? in fact, does KDateTime::fromString
> with TimeFormat ISODate already do what you need? (ditto for toString)

I tried to merge it but KDateTime is just too much for me. I cannot handle 
those timezone things right now. It will take me days to do that. Thus, I 
leave it for later although it is perfectly possible to merge 
KMetaData::Datatime into KDateTime. All I need is a time-only KDateTime. 
Well, anyway, I don't think it is a big issue since I can just hide Datatime 
from the API and replace it later on.

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

I did that using the Xemacs stuff.

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

I did not handle the Ontology yet since it is a big thing. I will, however, 
simply remove it from the public API.
As I already mentioned Ontology will become a generic class for representing 
ontologies. It will either parse ontology files or read ontologies from the 
rdf store and then provide localized names and comments for all classes and 
properties.

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

I prefixed all of the by KMETADATA_ and commented them in the Resource sources 
which I renamed to resource.h.in and resource.cpp.in.

> is the rcgen app meant to be installed? if so, perhaps it should have a
> less generic name as well?

I renamed it to kmetadata_rcgen. Not a beautiful name, sure, but it should do.

Is this sufficient to do the move to the kdelibs? In the end the move will not 
break BC or anything else. All we need is Soprano in kde-support and a nice 
cmake check that makes KMetaData optional.

Cheers,
Sebastian