[Nepomuk] Nepomuk-WebMiner integration into nepomuk-core fileindxer

[Vishesh Handa]

Hey Jörg

Sorry about the delay.

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.

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.

I'm hesitant of moving the webminer into nepomuk-core cause of the
following reasons -

* Stupid ideological reasons - The main package is called "nepomuk-core"
which is supposed to just contain the "core" functionality.
* Additional dependencies - These are optional so it really shouldn't be an
issue, but I'm still hesitant.
* 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.

Arguably, the new 'nepomuk-kde-config-ui' repo did not materialize, and we
stuck with kde-runtime.

* 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.

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?

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.

[1] http://community.kde.org/Projects/Nepomuk/Irc_meeting_nepomuk_frameworks

On Wed, Dec 26, 2012 at 11:11 PM, Jörg Ehrichs <Joerg.Ehrichs at gmx.de> wrote:

> The current indexing can than be controlled via the overall indexing
> status and shown in the nepomuk-controller that sits in the
> systemtray.
>

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.

The biggest problem might be the generation of the SimpleResource
> classes, which takes a very long time currently. Hopefully this can be
> fixed too, as this problem should be solved by any program that will
> use them in the future anyway.
>

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.

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.


> Any other ideas, suggestion or comments?
> Would the mentioned runtime python dependencies work or will they
> still be a problem?
> The good thing here, even if those runtime dependencies are missing,
> the user won't get a broken desktop. Instead the additional data will
> just not be fetched from the web.
>
> Regards,
> Jörg
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130108/f240f6e3/attachment.html>