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.
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>)
>
> 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>
--
Vishesh Handa
_________________________________________________
Nepomuk mailing list
[email protected] <mailto:[email protected]>
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>
--
Vishesh Handa
_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk
