Moving KFIleMetadata into KDE SC (documentation and ExtractionResult)

[Vishesh Handa]

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 
escriure:
> > 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.
> 

Fixed.

> 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
> enums?
> 
> 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 
property. 

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.

> Cheers,
>   Albert

Thanks for looking into this Albert.

-- 
Vishesh Handa