[Nepomuk] Re: [Kde-pim] akonadi nepomuk feeder problem, new nepomuk datamanagement service

[Sebastian Trüg]

DMS is part of KDE 4.7 actually. The only thing that is not yet there is
the client API. It is in kde-runtime still since it needs some
polishing. But since the client API is only a KJob-based wrapper around
async DBus calls DMS can easily be used without it.

Cheers,
Sebastian

On 05/22/2011 01:51 PM, Volker Krause wrote:
> On Sunday 08 May 2011 20:07:32 Christian Mollekopf wrote:
>> Hi,
>>
>> While working on a nepomuk note feeder for akonadi, I ran into a problem
>> which I'm not sure how to solve.
>>
>> The problem is, that the feederagents work with the nepomuk FAST classes.
>> Those classes side pass all checks,
>> and should therefore be faster. Unfortunately this implies that it is only
>> possible to add properties,
>> and not to change properties.
>>
>> So for notes I need to use
>>
>> res.setProperty( Vocabulary::NIE::description(), Soprano::LiteralValue(
>> note.text() ) );
>>
>> to set the text, so the note gets fulltext indexed. If addProperty is used
>> instead,
>> we end up with a new description property for every update, meaning all
>> versions of the text are available
>> and never removed.
>>
>> But since I cannot use the FAST classes because they lack the setProperty
>> call, and the NepomukFeederAgent base class
>> forces me to use the FAST classes we need some other solution.
>>
>> The obvious solutions would of course be to not use the FAST classes in
>> the first place (which might decrease performance for all feeders).
>>
>> But now I was talking to Sebastian Trueg, and he told me of a new
>> datamanagement service for Nepomuk living in the nepomuk/datamanagement
>> branch of kde-runtime.
>> This service adds new convenience functionality, such as automatically
>> adding info about the creator of resources, automatic handling of
>> dependencies when deleting resource (i.e. if the Thing should be also
>> deleted or if it is referenced by another resource). So in the long term I
>> think this dms is the way to go (although I don't know if this would
>> impose any performance problems, for i.e. the email feeder).
>>
>> I'm not sure though when we can start using it.
>> The dms will probably be available in kde-runtime for 4.7 and in kdelibs
>> 4.8 (according to strueg that is the current plan),
>> but afaik kdepim-runtime has no dependency on kde-runtime, so we would
>> have to wait for 4.8?
>>
>> Soooo, if the dms would go into kdelibs for 4.7 already, could we already
>> start using it in kdepim-runtime?
> 
> traditionally we depend only on the latest stable release of the KDE platform, 
> ie. KDE PIM 4.x has a minimum requirement of kdelibs 4.(x-1). So, a DMS in 4.8 
> would mean we can only start using it in KDE PIM 4.9. There might be ways 
> around this, like temporary forks of the necessary classes. Quite ugly of 
> course, but it allows the use of distro packages for KDE PIM development.
> 
>> Solutions for the initial problem, thoughts on the dms?
> 
> Sorry, can't really help with that, my contributions to the feeders mainly 
> focussed on the Akonadi side so far, I never looked into the details of what 
> we actually were doing there on the Nepomuk side ;)
> 
> regards
> Volker
> 
> 
> 
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk