porting kfilemetainfo to strigi

[Jos van den Oever]

When porting KFileMetaInfo to use Strigi, some issues have come up.

- Strigi only support extraction of text.
This is not enough and I will add more types. KFileMetaInfo can handle
QVariants. This is overkill for Strigi and would be a lot of work to
support. I'm not sure how many types I will support, but a binary
string will certainly be added.
Currently, for each field, the following function is called:
 setField(const Indexable*, const std::string& fieldname, const
std::string& value)
I want to add this function:
 setField(const Indexable*, const std::string& fieldname, void* ptr,
size_t size)
for binary data.
This leaves the need for integer and float types. These can be
represented as strings and this is how fields like width and heigth
are currently being represented.

- Strigi has no concept of groups for fields
Metadata in Strigi only have a fieldname and no group. Currently the
fieldnames are simple. I want to allow urls for fieldnames. These urls
then identify the fieldtype. This is how dublin core and nepomuk work.
Ideally, this identifies would also determine the type (string,
binary, int) and unit (cm, kg, eV). Grouping these fields would then
not happen on the level of the analyzer but must be handled some other
way. The same goes for translations of the field names.

- Strigi cannot edit fields
Are there any KFilePlugins that allow for editable fields that store
in the file itself? In combination with nepomuk, we can allow for
editable fields but if this data must be stored in the file itself, we
have to reconsider the current approach.

Apart from these issues, porting is coming along nicely. I'd
appreciate input with suggestions and opinions.

Cheers,
Jos

[1] http://dublincore.org/documents/dcmi-terms/
[2] http://freedesktop.org/wiki/Standards/shared-filemetadata-spec