[Kde-pim] Re: Broken Nepomukfeeders

Christian Mollekopf chrigi_1 at fastmail.fm
Thu May 19 12:34:59 BST 2011


For the record:

Today Sebastian and I finally figured out whats happening.
If a resource is created with the Nepomuk::Resource api, before the feeder  
item exists,
then the feeder cannot find the item it created to delete it before  
updating the info,
therefore the dataduplication.

I just pushed a workaround for this issue, so this shouldn't be a problem  
anymore.
I also pushed a fix for the initial indexing problem.

On Wed, 18 May 2011 01:29:37 +0200, Christian Mollekopf  
<chrigi_1 at fastmail.fm> wrote:

> On Tue, 17 May 2011 02:26:52 +0200, Christian Mollekopf
> <chrigi_1 at fastmail.fm> wrote:
>
>> Hi,
>>
>> I know I'm repeating myself, but my email that the nepomukfeeders are
>> broken in a number of ways didn't trigger any response so far.
>>
>> The current list of problems:
>> -All data is duplicated everytime something is updated (i.e. when a
>> calendar item changes)
>
> Actually, this is not true. After reading the code a bit more, and doing
> some tests,
> I noticed that normally all the old data of an item is removed first,
> before the new
> data is added.
> I know I had a setup where this dataduplication happened, but I suspect
> that this was
> due to MindMirror trying to work on the same resources.
>
> So, as long as there is no application which tries to modify the resource
> which the
> feeders create (Which is problematic due to the way the feeders create  
> the
> resource
> -> plain soprano statements), there shouldn't be much of a problem.
>
>> -Initial indexing doesn't work for me at least in some feeders (still
>> investigating in the problem)
>
> This seems to be related to my attempted fix, first removing each
> statement before adding a new one.
> In my latest test everything worked as expected.
>
>> -The created nepomuk resource are somewhat "wrong" (differing from what
>> the Nepomuk::Resource api would do),
>> which makes it hard to reuse the resources in other applications.
>
> As mentioned above, if no applications try to work actively (as writing  
> to
> resources) with the resources created by the feeders, I don't think any
> action
> is needed for the first release, and we can focus on a rewrite using the
> DMS for the
> next release.
>
> Sorry for the noise,
>
> Chris
>
>>
>> I don't know where in kdepim nepomuk is already used and how exactly,  
>> and
>> some issues might not be exactly critical
>> (i.e. if the email feeder does the initial indexing there is not much of
>> a
>> problem as emails are not updated/modified),
>> if possible I would however avoid shipping software like this.
>>
>> Except for the initial indexing problem, which might as well be a local
>> one, those issues are quite easy to fix and I would happily do it.
>> But since I haven't actually committed a single line of code to kdepim  
>> so
>> far, and the feature freeze is in place, I'm not really sure what to do.
>>
>> Volker doesn't seem to be around a lot these days, so maybe someone else
>> has some knowledge on the topic?
>>
>> I don't think the world will burn down either if we ship them like this,
>>
>> I'm just sayin'
>>
>> Cheers
>>
>> Chris
>> _______________________________________________
>> KDE PIM mailing list kde-pim at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-pim
>> KDE PIM home page at http://pim.kde.org/
>
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list