[Nepomuk] Bugs, Patches and Scripts. - StrigiService & KInotify

[Sebastian Trüg]

On 04/26/2010 05:59 PM, Vishesh Handa wrote:
>     While conceptually you are completely right I think it would be better
>     to make the FileWatcher update the strigi config. FileWatcher is taking
>     enough resources as it is by watching all the folders.
> 
> 
> I tried that, but then I required the StrigiServiceConfig class. So, I
> thought KInotify is more portable. But we don't want another resource hog!

You only need KConfig("nepomukstrigirc"). Nothing else. :)

>     I thought about doing it this way, too. But then twice the mem is used
>     and I figured watchingPath() and removePath() are not called very often.
>     Thus, the mem savings would be preferable. I suppose...
> 
> 
> The memory saved wouldn't be much. But, watchingPath() is only called in
> FileWatch::addWatch before adding a watch. The moment I see a TODO:
> Optimize. I just have to try! :)

No problem. Actually I think your patch is a good idea in any case since
watchingPath() never seemed to work anyway, resulting in the
Filewatchservice to recreate all watches whenever strigi updates the paths.

>     Why do you think it should do this? After all, addWatch does also
>     recurse into subdirs. Plus, we only stop watching a folder if it is
>     removed. In that case the subfolders are of no interest anyway. :P
> 
> True. But it doesn't seem logical. It serves the FileWatcher's purpose
> perfectly, but logically one would think removeWatch would just remove 1
> watch. Plus, who in the world would be watching a subdir when they are
> already watching it's parent. Maybe we could add another function which
> removes the other watches?

Well, watching the parent alone is of no use to us. That is why KInotify
is recursive by default. Remember: the class is not supposed to be
generic but only serve the filewatch service. I started out trying to
create a generic class but it is just a waste of time since we have
KDirWatch in kdelibs.

>     Only sibling? AFAIK the only problem is moving to a non-watched folder,
>     i.e. a folder outside the home dir or any indexed folder.
> 
> 
> Yes. And my code only watches the indexed directories first parent (cd
> ..). Hence the sibling thing. It was just the first patch where I was
> fiddling around.

Ah, ok, I did not see that.

> Btw, we need to do something about this. I have partitioned my hard
> disk, and they are mounted in the /media/ directory. The metadata mover
> just deletes the metadata. I was thinking about downloading the kernel's

I dont really follow.

> source code, and try to hack inotify, but then I've just compiled my
> kernel once in my life, and making modifications seems like a huge leap
> forward. :(

hacking on inotify is a bit much I suppose. Maybe we should rather talk
to the kernel people about the problems.

>     Thus, it can be simplified a lot by removing all the dirwatch details
>     and just keeping the slotMoved method. So in the end it is just one
>     method. Maybe no need for a class. :P
> 
> 
> I was mainly using this class for testing kinotify, I just changed the
> name and slapped on a couple of functions. I thought it wouldn't be
> right for me to just state the problem without even trying to solve it. 

:)

>     but I will see about making that public so we can collaborate. :)
> 
> Please do. Trying to debug the strigiservice while filewatch keeps
> spewing out debug messages is quite, well not difficult, but distracting.

That is very easy to solve:
You either:
1. disable all the other services' output in kdebugdialog
or
2. stop the strigiservice and run it on a dedicated shell:
"nepomukservicestub nepomukstrigiservice"

> So, what do we do now? Should I try to integrate it into the filewatch
> service?

that would be great. Like I said I think one method would be enough. And
for now it would be perfectly OK to simply rewrite the strigi config via
KConfig. Just use readPathEntry and writePathEntry to update the
folders. But make sure to only write data back if it actually changes. I
am not sure if KConfig already handles that.

> PS : I got an SVN account! :)

very good. :)

Cheers,
Sebastian