Actually I have planned to start on that API mid of next week since I need it for another project. Maybe a good idea to start would be to brainstorm on the necessary method the API would require, ie. come up with a bunch of use cases.
We could put that on techbase.kde.org... Cheers, Sebastian On 11/17/2010 02:24 PM, Bruce Adams wrote: > > That's pretty much exactly what I'm looking for. > So I'm happy to collaborate on any efforts to get something like that going. > > > Regards, > > Bruce. > > > ----- Original Message ---- >> From: Sebastian Trüg <[email protected]> >> To: [email protected] >> Sent: Wed, November 17, 2010 1:04:19 PM >> Subject: [Nepomuk] Re: nepomuk & gnome & firefox >> >> This is what I mean: a DBUs API that provides what the Nepomuk-KDE API >> provides at the moment. >> >> Cheers, >> Sebastian >> >> On 11/17/2010 09:58 AM, Bruce Adams wrote: >>> ----- Original Message ---- >>> >>>> From: Richard Dale <[email protected]> >>>> To: [email protected] >>>> Sent: Tue, November 16, 2010 5:40:17 PM >>>> Subject: [Nepomuk] Re: nepomuk & gnome & firefox >>>> >>>> On Wed, Nov 10, 2010 at 7:11 AM, Sebastian Trüg <[email protected]> wrote: >>>>> The solution is simply what I said: we support the tracker API and >>>>> that's it. The other way around is not possible anyway. >>>> OK, how would you like to support the tracker API? I'm still not clear >>>> on what you are saying. >>>> >>>> One way would be to write a Tracker backend for Soprano 2.x which >>>> would support a subset of the Virtuoso backend's functionality. >>>> >>>> Another way would be to write a QSparql based backend for Soprano 2.x >>>> which would interface with Tracker, and also support SPARQL endpoints >>>> and Virtuoso as a side effect, although you would be perfectly welcome >>>> not to use that extra functionality as the drivers are only plugins. I >>>> happen to be an expert on the Tracker apis (both the DBus one and the >>>> newer 'direct api'), and the Tracker team are cooperating to improve >>>> their api WRT its use in QSparql. I am also an active KDE developer >>>> who has developed language bindings for Soprano and Nepomuk, and I am >>>> quite happy to work on KDE things in my spare time. So if anyone can >>>> do this particular task I feel I should be about the person person to >>>> try. >>>> >>>> I don't know what your plans for Soprano 3.x are as I haven't studied >>>> the code yet. >>>> >>>> -- Richard >>> >>> >>> From my angle as a noob a lot of this is missing the point. >>> I want to read and write tag clouds in a platform independent way. >>> A rich ontology is all very well (and vitally important for more advanced >> uses). >>> But at the start of the day I want to be able to do something like: >>> >>> Nepomuk::File file( "some/path"); >>> file.addTag("foo"); >>> >>> Just like in the examples here: >>> >>> http://api.kde.org/4.x-api/kdelibs-apidocs/nepomuk/html/examples.html >>> >>> and see the tag "foo" appear in the "quickview" in dolphin and >>> the equivalent Gnome apps (and firefox). >>> >>> Surprisingly this is 'bleeding edge' stuff (kde 4.6) rather than the bare >>> essentials >>> and doesn't work on my up to date ubuntu 10.10 installation which is still >> on >> >>> kde 4.5.1. >>> (actually this is beyond the bleeding edge as the tag needs to be declared >>> first, but you get the idea) >>> >>> Regards, >>> >>> Bruce. >>> >>> >>> >>> _______________________________________________ >>> Nepomuk mailing list >>> [email protected] >>> https://mail.kde.org/mailman/listinfo/nepomuk >>> >> _______________________________________________ >> Nepomuk mailing list >> [email protected] >> https://mail.kde.org/mailman/listinfo/nepomuk >> > > > > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
