Another monday and again the Nepomuk-KDE question

Sebastian Trüg strueg at mandriva.com
Thu Apr 26 17:04:35 BST 2007


On Thursday 26 April 2007 17:06:07 Dirk Mueller wrote:
> On Wednesday, 25. April 2007, Sebastian Trüg wrote:
> > To be honest: I don't know if it will stay compatible. We could certainly
> > try enforcing it and only improve on the inside and by adding new stuff.
>
> So do you prefer to keep it non-BC until KDE 4.1 ? I guess that would be a
> way out: to mark the API as explicitely unstable.

If that is a solution that would work for you, sure. Marking it unstable until 
4.1 is a good solution. Then it will already have the exposure it needs 
without being restricted to API improvements (be aware that so far I can only 
think of one thing that I'd like to improve in the future: metametadata, i.e. 
information about who created which data when. But even that could be modeled 
BC although a clean solution would probably break BC.)

So, yes, marking it unstable until 4.1 works for me.

> > > This will be a hard dependency then for knepomuk and therefore for
> > > kdelibs, right? How much of nepomuk will work without it? Can
> > > applications discover existance of the nepomuk service at runtime or is
> > > it a compile time dependency?
> >
> > Services can be discovered at runtime and in theory you can do it using
> > plain D-Bus. But using knepomuk as a compile dependancy allows to use its
> > simple API to access and use the services much easier.
>
> so which applications/libraries will depend on these additional
> dependencies? only the kmetadata lib?

at this point, yes since ATM I am only working on the metadata part of 
Nepomuk-KDE. Since Nepomuk is also about social aspects (which basically 
means p2p for everybody, i.e. every application and metadata sharing across 
desktops) new services will spawn later. These will also be accessible via 
the knepomuk lib and the service registry.

Cheers,
Sebastian




More information about the kde-core-devel mailing list