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