[Nepomuk] Issues with non persistent filesystems/mounts and Nepomuk

[Sebastian Trüg]

On 06/15/2010 01:54 PM, Daniel Winter wrote:
> 2010/6/15 Sebastian Trüg <trueg at kde.org>:
>> Well, maybe the simplest solution would be to ask the user on unmount.
>> Let them decide if we want to keep the data, make it portable, or remove
>> it....
> 
> Could work, if the unmount happens when a user is using the system. I
> mean an unmount could happen at logout or shutdown. A view for every
> filesystem in the Nepomuk KCM would help. One could there delete all
> resources on it (for example if a lost the usb hdd), enable exporting
> of data and so one.

That is a nice idea, yes.

> On the technical side, what would be the difference betwen a portable
> and not portable filesystem? Only the portable resources would have a
> link to the filesystem they are on?

Portable resources would have filex:/ nie:urls.

> Another question:
> 
> Could an application link to a filex: or nepomuk: url for example in
> recently used files or in a playlist? I mean sure it could,  but
> nepomuk:/ uris will become filex uris sometime in the future, right?

nepomuk:/ URIs never change. That is the whole idea.

> Consider this:
> 
> I mount a big usb hdd and select it's path or some of them for
> indexing in Nepomuk.
> 
> Nepomuk will index them using nepomuk://  urls.  And nie:url pointing
> the real path on filesystem level.  That correct?

yes

> Then on unmount  Nepomuk detects the unmount and has to rewrite every
> nepomuk: uri to a filex:/ uri?

no. Like I said: the nie:urls are rewritten. The resources are untouched.

> Or still wrong? Does it already use filex: on first index?  Also what
> about things like rating a file on such da filesystem (when indexed or
> not indexed)

Ratings are handled in the exact same way. Nepomuk::Resource matches
local file paths to existing filex:/ nie:urls.

The system works very well. Its only problem is the performance with
many files.

Cheers,
Sebastian