Nepomuk Collection

[Matěj Laitl]

On 9. 11. 2012 Phalgun Guduthur wrote:
> Hello all

Hi,

> After a period of inactivity, I want to continue working on the Nepomuk
> plugin for Amarok and implement a few more features before it is shipped.

Good!

> These are the major problems of the plugin currently -
> 
>    - The collection takes some time to load  (10s for 2000 tracks). This is
>    because of the use of MemoryCollection.
>    To write my own QueryMaker, I need considerable amout of time as I'm
>    completely clueless about it. Any help on how to go about this would be
>    great.
>    Stecchino once mentioned to have a look at UPnP collections
>    implementation.

Yes, and also the SqlQueryMaker. The idea is to build the SPARQL query in the 
calls like addMatch(), addFilder() etc, and to run it asynchronously in the 
run method. You'll probably need a cache of "live" NepomukMeta entities (a map 
from Nepomuk URIS to Meta::* instances), something like SqlRegistry, although 
hopefully not that complicated.

>    - After a restart of Amarok, the tracks in the playlist view get fetched
>    from the Local Collection instead of Nepomuk collection. This is because
>    the Nepomuk collection slow loading of tracks.
> 
>    Is there a way to delay the fetching of meta data for tracks in the
>    playlist view until the Nepomuk collection is fully loaded?
>    The function Playlist::Model::metadataChanged(Meta::TrackPtr) must be
>    delayed.

Probably not. There are more flaws in our restore-tracks-from-urls code, so it 
maybe needs to be reworked. On the other hand, after you have your own 
QueryMaker, only thing a Nepomuk::Tracks needs to store will be the Nepomuk 
URI, other fields would be fetched using Nepomuk on demand. (perhaps with 
caching?)

Then you can create Nepomuk::Tracks really quickly in trackForUirUrl() and the 
problem goes away.

>    - Implementing Nepomuk::ResourceWatcher, so that tracks when changed by
>    other applications are reflected immediately in Amarok. This includes
>    addition of new tracks, deletion, change in metadata etc.
>    But this needs the code to be ported to Nepomuk2 ( The newer, sleeker
>    API of Nepomuk ). I'm finding it tough to get Nepomuk2 work on my
> machine.

Yes, please do the porting ASAP, reportedly it is mainly just a namespace 
change. Connecting Nepomuk::ResourceWatcher to Track::metadataChanged() should 
be trivial.

>    - Write back support - let the user edit meta data of his tracks through
>    Amarok. Right now the edit fields are all grayed out.

Yep. I suggest you assign this a lower priority than the NepomukQueryMaker 
though. Not strictly needed for Amarok 2.7, where we can label Nepomuk 
collection as "technology preview" if it lacks iportant features.

>    - Support for creating playlists

Nice, again lower priority than QueryMaker IMO, not needed for Amaork 2.7.

>    - Support for storing scores of tracks - needs ontology support which is
>    a whole different thing.

Score is IMO much less used than rating, first & last play, so low prio from my 
PoV.

> I write this seeking any sort of feedback on the above problems either on
> how to tackle them or their importance.
> 
> What do you think is the most important feature that should be implemented
> before the plugin is shipped?

QueryMaker and related refactor, if you think you can manage it by the end of 
November.

Cheers, high five and good luck,
	Matěj