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