On Mon, Dec 10, 2012 at 6:55 PM, Sebastian Trüg <[email protected]> wrote:
> Very good. :) > Sorry for not being active anymore. These past 2 weeks I have been > "working" on my new-born son. Apart from that I am pretty busy with > OpenLink work. I will try to at least look at the review requests more > frequently. Don't worry about it. I get it. 3 kids + work is a lot. I'll try to only put the really important ones under your name. I hope work is going well :) > > > On 12/10/2012 02:18 PM, Vishesh Handa wrote: > >> Quick update - >> >> Right now the plan is to implement this for 4.11. >> >> >> On Tue, Nov 27, 2012 at 1:53 AM, Sebastian Trüg <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 11/23/2012 11:17 AM, Vishesh Handa wrote: >> >> >> >> >> On Fri, Nov 23, 2012 at 3:30 PM, Jörg Ehrichs >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>**> >> wrote: >> >> 2012/11/23 Marco Martin <[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> >> <mailto:[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<https://bugs.kde.org/show_bug.__cgi?id=310525> >> >> <https://bugs.kde.org/show_**bug.cgi?id=310525<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? >> >> >> It would be slightly more expensive, but not too hard. One would >> have to >> retrieve the resource for each file resource till the root >> element. So >> if you give me something like this >> Resource("/home/vishesh/kde/__**src/file.cpp") >> >> >> I'll have to do either multiple queries - >> >> select ?r where { ?r nfo:filename "home" ; nie:isPartOf >> <rootElement> . >> } -> homeRes >> select ?r where { ?r nfo:filename "vishesh" ; nie:isPartOf >> <homeRes> . } >> -> visheshRes >> .. >> .. >> or maybe it can be done in one query? >> >> >> I think so: >> >> select ?r where { ?r nfo:filename "file.cpp" ; nie:isPartOf [ >> nfo:filename "src" ; nie:isPartOf [ nfo:filename "kde" ... ] ] } >> >> I am, however, not sure which is faster. >> >> In general I like the idea to get rid of file URL, a lot actually. >> This could even mean that you get rid of nie:url alltogether. In the >> end there is really no need to use nie:url for http or any other >> remote resource... >> >> As for your (3): that should actually be fairly simple. I wrote the >> code, which feels very hacky (not the code itself, but the need for >> its existance) and it could easily be adapted to only update >> nfo:filename and nie:isPartOf. Much simpler in the end. >> >> All in all: +10 from me if you can get the direct file resource >> access fast. >> >> Cheers, >> Sebastian >> >> >> You get the gist. These all could be cached in memory so it >> shouldn't be >> a big problem. This is actually quite analogous to what the >> kernel does >> in the file system later, except that it matches inodes to their >> filename. We will be matching resource uris. >> >> I'd say retrieving metadata from a file is a "one-time" job >> of 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. >> >> >> Of course. This all should be transparently handled in the >> resource class. >> >> 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. >> >> >> Yeah. I think so as well. >> >> But it's a BIG change. All the previous data will first need to >> be ported. >> >> ______________________________**___________________ >> Nepomuk mailing list >> [email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> >> >> https://mail.kde.org/mailman/_**_listinfo/nepomuk<https://mail.kde.org/mailman/__listinfo/nepomuk> >> >> >> <https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk> >> > >> >> >> >> >> -- >> Vishesh Handa >> >> >> >> ______________________________**___________________ >> >> Nepomuk mailing list >> [email protected] <mailto:[email protected]> >> >> https://mail.kde.org/mailman/_**_listinfo/nepomuk<https://mail.kde.org/mailman/__listinfo/nepomuk> >> >> <https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk> >> > >> >> ______________________________**___________________ >> >> Nepomuk mailing list >> [email protected] <mailto:[email protected]> >> >> https://mail.kde.org/mailman/_**_listinfo/nepomuk<https://mail.kde.org/mailman/__listinfo/nepomuk> >> >> >> <https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk> >> > >> >> >> >> >> -- >> Vishesh Handa >> >> -- Vishesh Handa
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
