<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 8:59 PM, Jörg Ehrichs <span dir="ltr"><<a href="mailto:Joerg.Ehrichs@gmx.de" target="_blank">Joerg.Ehrichs@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/1/8 Vishesh Handa <<a href="mailto:me@vhanda.in">me@vhanda.in</a>>:<br>
<div class="im">> Hey Jörg<br>
><br>
> Sorry about the delay.<br>
<br>
</div>No problem :)<br>
<div class="im"><br>
><br>
> Would it really be that much effort to copy the indexing queue in the<br>
> webminer service? Additionally the fileindexer could even emit signals when<br>
> its queue finishes one file so you can pick it up. If required.<br>
<br>
</div>Not really to much effort. I just like to avoid copying stuff around.<br>
But I fully understand all the issues against the nepomuk-core<br>
inclusion.<br>
How about I stay with the Nepomuk2::Service part (I use at the moment)<br>
but instead of the ResourceWatcher I stick with the kext:indexingLevel<br>
solution<br>
that the file indexer uses.<br>
<br>
So the service runs with a copy of the eventmonitor for proper<br>
suspend/resume on idle/diskspace/battery (and Network) limitations<br>
and checks for the next 10 resources with mimeytpe pdf/video/audio<br>
that have kext:indexingLevel == 2.<br>
After the webminer was executed, no matter if successful or not the<br>
resources gets kext:indexingLevel 3.<br>
<br>
Does this sound like a better solution?<br></blockquote><div><br></div><div>That sounds perfect.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>><br>
>> The current indexing can than be controlled via the overall indexing<br>
>> status and shown in the nepomuk-controller that sits in the<br>
>> systemtray.<br>
><br>
><br>
> It would complicate the code, but we could make it control multiple sources<br>
> - file indexer + webminer. Actually, I think that is a good idea specially<br>
> cause it should also be controlling the akonadi indexing.<br>
<br>
</div>I believe the controller needs to be changed anyway (no matter what<br>
solution I would select, the way it is now it doesn't show much<br>
information in the one string)<br>
First it might be nice if the suspend/resume button throws a signal<br>
via dbus (in case it doesn't do this already).<br>
Adding proper output to show is a nice task for later</blockquote><div><br></div><div>I agree. <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">.<br>
<div class="im"><br>
><br>
> I'm hesitant of moving the webminer into nepomuk-core cause of the following<br>
> reasons -<br>
</div>> [...]<br>
<div class="im">><br>
> * Splitting of the webminer - I like the code being in one place. You'd have<br>
> to split the miner into the ui parts / core parts.<br>
><br>
> Overall, these reasons aren't that serious, but I still feel quite uneasy.<br>
> That's the main reason why I took so much time to reply. Maybe someone else<br>
> could tell their opinion?<br>
<br>
</div>I'm fine with your reasons, especially as I don't like to split<br>
core/ui parts here.<br>
Annoying enough that it took me a while to find where the nepomuk kcm<br>
was hidden.<br>
<br>
All I need is a "proper" way to integrate the service into the system properly.<br>
I don't like opening the webminer ui every time I have a new file,<br>
when the same thing can be done automatically.<br>
<br>
So if the service way mentioned above together with a copied part of<br>
the indexingqueue and the kext:indexinglevel is<br>
a good solution i'll implement this and we can move the complete<br>
webminer repo (after polishing) somewhere into SC<br>
wherever it might fit.<br></blockquote><div><br></div><div>Great. Let me know if I can help :)<br><br></div><div>One thing that I have found works is putting up small tasks ( or junior jobs ) for the simple stuff. Lots of people seems to be interested in contributing to Nepomuk these day :D<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>> The biggest problem might be the generation of the SimpleResource<br>
>> classes, which takes a very long time currently. Hopefully this can be<br>
>> fixed too, as this problem should be solved by any program that will<br>
>> use them in the future anyway.<br>
><br>
><br>
> I don't think everyone will agree with me, but I think the code should be<br>
> pre-generated and saved. The main reason for this is that we have had<br>
> problems when SDO has been changed in a way that the nepomuk-rcgen produces<br>
> different code. This happened when we had set the max cardinality of a lot<br>
> of properties. It resulted in the method signature changing. Eg -<br>
> setFullNames( QList<> .. ) to setFullName( QString ). We eventually had to<br>
> patch up rcgen to generate both the functions.<br>
><br>
> Also, since we do not guarantee that the generated files will maintain<br>
> source compatibility, it seems better if one could just re-generate them<br>
> before each release, and fix the problems as they arise.<br>
><br>
<br>
</div>Well we had the discussion in a lengthy way in kde review.<br>
All in all it would be nice to generate the files on the fly, but<br>
packagers really hate it.<br>
<br>
I hope we can add the generated files back into the repo later.<br></blockquote><div><br></div><div>I really don't understand why they hate it. Both ways it is getting compiled.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Cheers,<br>
Jörg<br>
</blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br>
</div></div>