Moving KFIleMetadata into KDE SC (documentation and ExtractionResult)
me at vhanda.in
Wed Jan 22 10:48:23 GMT 2014
On Wednesday 22 January 2014 00:23:45 Albert Astals Cid wrote:
> El Divendres, 17 de gener de 2014, a les 18:03:31, Vishesh Handa va
> > Hey guys
> > I should have posted this with the Baloo thread, but since I did not -
> > WIth KDE SC 4.10, Nepomuk dropped support for Strigi and implemented their
> > own indexing library. This code was part of nepomuk-core. With Baloo, this
> > code has been migrated into its own repository called kfilemetadata. I'm
> > hoping to make it into its own framework some point in the future.
> > I would like to move this code into KDE SC along with Baloo.
> > None of the code is new. It has all been taken from neopmuk-core. The only
> > change is that the indexers no longer use the ontologies.
> Can you have a look at
> virtual void extract(ExtractionResult* result) = 0;
> It seems to me that the documentation is wrong, it lists lots of params.
> Also i tried looking at ExtractionResult and without documentation i'm not
> sure i'd be able to use it, could you add some docu and/or example?
I've improved the documentation to a certain extent. I'll try adding an actual
example later. Maybe once I've figured out the property system (see below)
> Also I was wondering what is if we could move from all those strings to
> I mean
> result->add("copyright", it.value());
> is a bit hard, since whatever reads the result has to know it has to query
> for "copyright".
I've been trying to build a property system which would incorporate -
1. Actual names instead of strings
2. Property ranges. Eg - height should be an integer
3. Property name translations - The way translations are currently handled is
ugly. It works, but it is ugly.
4. Should the property be globally indexed - Some properties should not
globally indexed, and should only appear when the user searches for that exact
RDF provided a nice way to specifying all of this, but I'm not too keen on
using RDF. In the end, I may just use enums, but for now strings it is.
> Also i am wondering why addType is virtual and append/add are pure virtual.
I thought the derived classes may not care about the type. I've changed it to
pure virtual to be more consistent.
Thanks for looking into this Albert.
More information about the kde-core-devel