Nepomuk in 4.13 and beyond

[Simeon Bird]

> Could you please enumerate what all that involves? From what I know there is -
> 
> 1. Metadata model for running queries
> 2. Timeline based stuff - again, queries
> 3. Showing File metadata - There is a File class and a FileFetchJob
> 4. File ratings/comments - There is no API right now as I haven't decided how 
> to store them. Simeon (an awesome Nepomuk contributor) had the idea of storing 
> them as extended attributes. I still need to investigate more, but it seems 
> like a good idea.
> 5. Tags - read below.
> 
>> how are tags related to data in different stores?
> 
> The initial idea was to have a different TagStore which stores information 
> about tags such as their name, color, icon, etc. Additionally there would be a 
> TagRelation class which connects anything with a tag.
> 
> Have a look at baloo/src/tags/. The code has a large number of unit tests.
> 
> That being said, during the PIM Sprint we established that we want server side 
> tags w.r.t emails and other PIM data. This means two different ways of 
> accessing tags. I was thinking of throwing away the concept of tagging 
> anything, and only allow tagging of files. This way we could store the tag 
> metadata in the extended attributes for a file. From what I hear, Mac also 
> stores tags as extended attributes.

(Just to extend this idea a little for the record)

What mac does is indeed to store tags in an xattr. On fat, which does
not support xattrs, it creates a hidden file, called something like
.__filename_xattr (I forget the exact name) to store the xattr data.

So if we were to do this and support removable media we would need to
alter kdelibs to support this or a similar way of storing xattrs
somehow. Is that doable or sensible?

Advantages I can see are:

- it helps a lot with all the file watching stuff; we would no longer
have to instantly install watches all over removable media, with the
attendant problems.
- cp -a would preserve metadata, while cp would not, which makes sense
- it is the only way I can see of cleanly fixing bug 326442, which
happens because KSaveFile does a create/unlink/rename, and nepomuk sees
the unlink and deletes the metadata.
- Using dolphin or another kdelibs based filemanager to move files while
the file watcher isn't running would no longer lose tags.

[The flipside to this one is that using, eg, thunar when the search
indexer *is* running to transfer files to an external drive could lose
tags when it would not have before, but this could in principle be fixed
by submitting a patch to thunar, etc.]

There could be a secondary goal of being compatible with the mac
implementation, which might or might not be worth it.

Simeon