<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 7, 2012 at 9:27 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">Hi Vishesh,<br>
thanks for the input.<br>
<div class="im"><br>
><br>
> 1. You have multiple extractors - One for resources which extract<br>
> information from the file, and some web-extractors. Considering that Nepomuk<br>
> now allows easy Qt based extractor plugins, how about we move your code over<br>
> there? Your poppler based code would be quite useful. Same goes with the<br>
> ODF.<br>
><br>
<br>
</div>Yes, when I've started the project the new file extractors wasn't available.<br>
I do intent to switch to the new fileindexer way combined some the<br>
current filename analyzing<br></blockquote><div><br>File name analyzing?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(unless this can go into the fileindexer too)<br>
About moving the pdf/odf analyzer over. I thought you already copied<br>
the important parts to the new indexer?<br>
If they are still missing, I'll add them later on.<br></blockquote><div><br>I was hoping to find some library to do the odf parsing. Also, your poppler based analyzer tries to get the title from the first page. That seems pretty cool.<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>
> 2. Project Name - If one moves the extractors away, the only part that is<br>
> left is the web-extractors. Why not rename the project to<br>
> Nepomuk-WebExtractor or something similar? I know a project by that name<br>
> already exists, but that can be removed. It's a dead project.<br>
><br>
<br>
</div>If we can ignore the naming issue with the "old" project, I really<br>
like to rename it to Nepomuk-WebExtractor as this<br>
fits the purpose of the system the most.<br></blockquote><div><br>I think we would have to file a systemadmin request for this. Maybe we can append gsoc to the orignal projects name. I don't think it would be correct to just throw it away.<br>
 <br>Does anyone have any opinions about this? ( We should obviously email the original author (Artem - 2010 gsoc) )<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>
> 3. I would eventually like this to be a part of the KDE SC release. Web<br>
> Extractors are something that I have wanted for a very very long time. I'm<br>
> not sure if we can get this into 4.10, but I'd definitely like it to be a<br>
> part of 4.11.<br>
><br>
<br>
</div>I would like to be part of KDE SC, i assume its way to late for 4.10<br>
due to feature freeze but 4.11 sounds nice too.<br>
I could go extragear for now and move it back to kde-runtime when<br>
master is unfrozen again?<br></blockquote><div><br>+1<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>
> As to where it should be placed. I agree with Sebastian Kugler, kdelibs is<br>
> not the place. We had initially planned on splitting kde-runtime/nepomuk<br>
> into multiple repositories, but we're now waiting for KF5. Do you think this<br>
> could go under kde-runtime (not in that repo)<br>
><br>
<br>
</div>Just wonder if runtime is the really best place.<br>
Beside the fact that its a standalone program, it also can serve as a<br>
library which can be used by others.<br>
While this is mostly a "like to have case" the additional searching<br>
capabilities could be nice in<br>
Bangarang, Amarok, Okular and other programs working with media files.<br>
Would such a library component<br>
still fit into runtime? Or should is just ignore this fact for now, as<br>
it is unlikely that this will be integrated<br>
into other programs is the near future.<br></blockquote><div><br>I see your point. Now even I'm confused. It seems to come under the same category as nepomuk-core which contains libraries and runtime components, which the libraries require.<br>
 <br>Anyway, we won't have to figure this out for a couple of month at least.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 4. ResourceWatcher - [...]<br>
<div class="im">><br>
> This way, you would avoid using the ResourceWatcher, and everything would be<br>
> better integrated. But I'm not sure how we would go about this, so lets<br>
> stick with the current architecture for now.<br>
><br>
<br>
</div>This sounds like a nice idea. We can figure something out I do have a<br>
few ideas in this area, but not really<br>
the time to work on such large changes at the moment.<br>
<div class="im"><br>
><br>
> 5. Auto generated SimpleResource Headers - You've included them in your<br>
> repo. That was what we originally wanted. We didn't want to repeat the mess<br>
> that happened with breaking kdepim cause of ontology changes.<br>
><br>
<br>
</div>Got to know this was the intended way to go.<br>
<div class="im"><br>
><br>
> Does anyone have a problem with having generated headers in the code? One<br>
> could generate them on the fly, but that would be slow (Jorg says around 10<br>
> minutes?) and if something is changed in the ontologies, the classes would<br>
> change drastically thereby affecting the code.<br>
><br>
<br>
</div>I could push my latest changes which allows to easily use a cmake<br>
switch to generate updated ontology classes.<br>
This would combine both solutions, as long as it is fine to add such<br>
generated classes into the repo.<br>
<br>
Cheers,<br>
Joerg<br>
</blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br><br>
</div>