<div dir="ltr">Hey Jörg<div><div class="gmail_extra"><br></div><div class="gmail_extra">Sorry about the delay. <br><br>I have been thinking about this for quite some time. My main issue is if we should be shipping this with nepomuk-core. Even though it would greatly simplify suspend/resume and indexing. I think it would be better for it to stay in another repository.<br>

<br></div><div class="gmail_extra">Would it really be that much effort to copy the indexing queue in the webminer service? Additionally the fileindexer could even emit signals when its queue finishes one file so you can pick it up. If required.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm hesitant of moving the webminer into nepomuk-core cause of the following reasons -<br><br></div><div class="gmail_extra">* Stupid ideological reasons - The main package is called "nepomuk-core" which is supposed to just contain the "core" functionality.<br>
</div><div class="gmail_extra">* Additional dependencies - These are optional so it really shouldn't be an issue, but I'm still hesitant.<br></div><div class="gmail_extra">* KCM module - I assume that if the webminer is moved into nepomuk-core, you would also move the web-miner kcm? When we decided to split the modules [1] we wanted to split the UI and core parts.<br>
<br></div><div class="gmail_extra">Arguably, the new 'nepomuk-kde-config-ui' repo did not materialize, and we stuck with kde-runtime.<br><br></div><div class="gmail_extra">* Splitting of the webminer - I like the code being in one place. You'd have to split the miner into the ui parts / core parts.<br>
<br></div><div class="gmail_extra">Overall, these reasons aren't that serious, but I still feel quite uneasy. That's the main reason why I took so much time to reply. Maybe someone else could tell their opinion?<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Otherwise, one could just stick with the webminer repo, polish it up and move it into KDE SC. That way users won't have to choose to install it.<br><br>
</div><div class="gmail_extra">[1] <a href="http://community.kde.org/Projects/Nepomuk/Irc_meeting_nepomuk_frameworks">http://community.kde.org/Projects/Nepomuk/Irc_meeting_nepomuk_frameworks</a><br><br><div class="gmail_quote">
On Wed, Dec 26, 2012 at 11:11 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>It would complicate the code, but we could make it control multiple sources - file indexer + webminer. Actually, I think that is a good idea specially cause it should also be controlling the akonadi indexing. <br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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></blockquote><div><br></div><div>I don't think everyone will agree with me, but I think the code should be pre-generated and saved. The main reason for this is that we have had problems when SDO has been changed in a way that the nepomuk-rcgen produces different code. This happened when we had set the max cardinality of a lot of properties. It resulted in the method signature changing. Eg - setFullNames( QList<> .. ) to setFullName( QString ). We eventually had to patch up rcgen to generate both the functions.<br>
<br></div><div>Also, since we do not guarantee that the generated files will maintain source compatibility, it seems better if one could just re-generate them before each release, and fix the problems as they arise.<br><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Any other ideas, suggestion or comments?<br>
Would the mentioned runtime python dependencies work or will they<br>
still be a problem?<br>
The good thing here, even if those runtime dependencies are missing,<br>
the user won't get a broken desktop. Instead the additional data will<br>
just not be fetched from the web.<br>
<br>
Regards,<br>
Jörg<br>
_______________________________________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/listinfo/nepomuk</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br>
</div></div></div>