2012/11/23 Marco Martin <[email protected]>: > On Friday 23 November 2012, Vishesh Handa wrote: > >> <nepomuk:/res/23161f9c-8839-4de3-bba0-affdd6d654ef> >> rdf:type >> nmm:MusicPiece >> rdf:type >> nfo:FileDataObject >> rdf:type >> nfo:Audio >> rdf:type >> nie:InformationElement >> nie:url >> file:///home/vishesh/Music/where_does_the_good_go.mp3 >> >> Storing this URL makes accessing file resources quite convenient. But I >> fear it has been a terrible design decision. By storing the url we face the >> following problems - > > uhm, probably is right, keeping the full file url consistent is a mess, > however... > > a very common use case is in the c++ code, doing Nepomuk2::Resource(file path) > > needing a fast way to obtain the resource associated to a particular file > (like in https://bugs.kde.org/show_bug.cgi?id=310525) > > otherwise how could be done quickly to have the metadata of a file given we > have the file, and the other way around?
I'd say retrieving metadata from a file is a "one-time" job pf the file-indexer. Afterwards, we should rely on the data inside Nepomuk and only get more once this fails. In addition, the nepomuk-core part could offer a convenient method to create the file url for the end-user and also cache this information for a while to speed up the query. I assume its faster to check QFile::exists() than creating the url with every query again. Other than that, I like the idea. It seems there are several problems with remove able media, which doesn't seem to get solved with the current way. _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
