[Nepomuk] syncing nepomuk <-> exif metadata: recent changes, storage service hooks?

[Kristian Rink]

Hey Vivesh;

and first off, thanks a bunch for your comments, greatly appreciated!

[...]
> > (a) check Nepomuk service to get a list of image resources which have
> > recently (since last checked?) seen a metadata update,  or
> > 
> > (b) hook some handler / extension into Nepomuk Storage Service to
> > automatically do this sync whenever some kind of image resource is being
> > updated.
>
> Right, the fundamental difference between the two approaches in polling vs
> reacting to changes. (b) can easily be done with the ResourceWatcher, which
> was introduced in KDE 4.9. It is part of the nepomuk-core package.

Aah, I see. Thanks for pointing me there, this seems pretty much what I was 
looking for, at least conceptually. :)


> We have a gsoc project in 2011 called Metadata writeback. The main aim was
> to write plugins which would register the rdf:type, they were interested
> in, and the service, using the resource watcher would inform them when they
> should write-back the changes for that particular file. It is still in a
> branch, and should be merged. It requires some polishing, but nothing that
> should take too long.

I would definitely be interested in seeing this. Have been discussing this 
issue with the gwenview maintainer on the kde-imaging mailing list initially 
wondering whether this should be an extension to gwenview, but at closer look, 
this kind of syncing metadata back to structures in files to be "portable" 
seems something that possibly should not be done inside a Nepomuk "client" 
application. It seems to affect just too many different applications (modifying 
image data in gwenview vs. doing the same in dolphin, to start with). 


> The problematic part is using "PyKDE4". As far as I know python bindings
> for nepomuk-core still have not been generated. I'll write an email to the
> binding folk after this reminding them.

Thanks in advance for that. :) 


> If you don't want to wait for a proper solution, you can write a simple app
> using the ResourceWatcher. The only slightly problematic part is that once
> the resource is changed, and you writeback to the file, the file indexer
> will pick it up again, and this will lead to an infinite cycle. We will
> need some way to inform the file indexer to temporary ignore change to this
> file.

Yes, that's what immediately came to my mind about that, as well. To me, 
however, this seems one of the major motivations to write metadata inside 
something like a "propertyAdded" handler and, so, at least making sure the 
system still keeps full control on what happens to image metadata. Plus, of 
course, my current Python/PyKDE4/pyexiv2 based approach is exclusively 
tailored towards being used with JPG images, but this would make sense for at 
least all kind of files that can bear metadata...

But I will need to take a deeper dive into these issues first, anyhow. Came to 
KDE just a few months ago after being a long term XFCE user, came here mainly 
because of Nepomuk and the whole KDE infrastructure (which is pretty great), 
am modestly experienced with building server-sided and "semantics aware" 
applications using Java EE infrastructure and Python/Jython for scripting, 
then and now, so working with / building on top of kdelibs still is sort of 
new to me, though I have to say the documentation (API references, to start 
with) is pretty good and straightforward.

> I can add a dbus call for that, if you want.

Thanks for that, as well  - I'll get back to that as soon as I'm closer to 
making meaningful use of this. Meanwhile, thanks a load for your help on that! 
:)

Cheers,
Kristian