[Nepomuk] Handling filex:/ urls

[Sebastian Trüg]

On 07/14/2010 07:16 PM, Andrew Lake wrote:
> Sebastian Trüg wrote:
>> The whole filex:/ situation is a bit weird. I am not sure yet on how to
>> solve it. Currently you can ask the removablestorageservice to translate
>> the filex:/ URL into a local file:/ URL. It has a DBus method for that
>> which is also used in Nepomuk::Resource.
>> That said it could make sense to add functionality to Nepomuk::Resource
>> to expose the local path of a file.
> 
> That would be very helpful.

Actually IMHO a KIO::stat with a check for UDS_LOCAL_PATH afterwards
seems like the KDE'ish way to go about that, right? That would mean we
would need a simple filex:/ KIO slave.

>> I think we need to discuss the whole issue with removable media again.
> It may be helpful to separate indexing as just one of many potential
> paths for adding/updating metadata in the store. Apps will
> increasingly become one of the primary mechanisms for storing file
> metadata since many primary use cases for metadata will emerge from
> the apps, not just from the Search use case served by the indexer.
> e.g. NUAO metadata.

Indexing is already separated, both on the data level via
nrl:DiscardableInstanceBase and on the app level via the optional strigi
file indexing service.

>> Should the files be indexed?
> As long as there are legitimate use cases for storing metadata of
> those files, whether technically extractable or not, then it probably
> makes sense to allow them to be indexed. Perhaps not indexed by
> default, but certainly if the user specifies.

For now we have only one option to enable or disable indexing of files
on all removable media. The question is if we need something more
fine-grained. Should we ask the user for each and every mouted media?

>> Should the metadata be removed when unmounting?
> I don't think the metadata should be remove.  All the metadata would
> have to be recreated once remounted, which might take some time. Plus
> non-technically-extractable metadata could not be recreated and would
> be lost.  More to the point though is that there are many legitimate
> use cases that employ the metadata of even unmounted files. E.g. What
> is my most played artist or album, number of movies for my favorite
> actor/director, highest rated songs in a genre, etc. This information
> can be useful even if the user doesn't actually need to use the
> corresponding resource(s) at that moment.  Apps (or the indexer) can
> always provide a mechanism that allows the user to explicitly remove
> metadata associated with any resource, mounted or not.

Nice. So you basically agree with the way it is done at the moment. That
is good to know. That means we "only" have to improve certain situations.

>> But then we have the same problem again: the fat partition
>> you mention is not removable as far as the user is concerned. How to
>> detect that?
> No need to: If the nie:url property starts with "filex:/" then the app
> would be responsible for retrieving the correct url.  A separate
> fileExists type of check on the retrieved url will permit the app to
> inform the user if a resource is not available for use.  So long as it
> is mounted, removable or not, it would be transparent to the user.

the exists would again be done via KIO::stat on the filex:// URL for
which we need the simple filex:/ kio slave again (btw: filex:/ is a
stupid name, media:/ might have been better)

> It might have been nice if there was a way to retrieve the components
> of the correct url via a SPARQL query. Something like a (nie:isPartOf)
> nfo:RemovableMedia class that would have uuid and mountPoint (and
> maybe isMounted?) properties. These nfo:RemovableMedia properties
> could be updated when the device is mounted or unmounted. We might
> even be able to do away with "filex:/" altogether: The nie:url
> property could just be a pure relative URI that would be resolved to
> an absolute URI using the mountPoint property of the associated
> RemovableMedia as the base URI. It's a QUrl one-liner:
>     correctUrl = mountPointUrl.resolved(nieUrl)

All that information is already stored. The problem with relative URLs
is that file:/ does not allow for relative URLs. That is why I
introduced filex:/ in the first place. It is a relative URL - only
containing the media id in addition. That could easily be removed if
necessary.

> There might even be some general semantic desktop benefits of having
> an nfo:RemovableMedia class.

I don't see that yet. What is the benefit as compared to a simple
nfo:FileSystem?

> Anyway, as always, thanks for your help Sebastian!

pleasure as always. :)

> peace and much respect,
> Andrew Lake
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>