GSoC 2012 : Improvised proposal for 'Semantic Collection for Amarok'

[Matěj Laitl]

On 2012-03-22, Phalgun Guduthur <phalgun.guduthur at gmail.com> wrote:
> I have been working towards the 2012 GSoC idea 'Semantic Collection for
> Amarok' since a month now. I have already sent in my first rough draft of
> the proposal.
>
> At that time, I promised a proof of Concept and you can it submitted on the
> review board https://git.reviewboard.kde.org/r/104369/
> 
> It is a small patch demonstrating the read and write of Nepomuk index
> through Amarok.

I was very positively surprised how simple the patch is, good!

> I have also attached my improvised proposal after interactions with both
> the mentors Teo and Vishesh.
>
> Please review my proposal whenever you find time. Any feedback is
> appreciated.

Hey, the proposal is very good. If I have a chance to implement the inter-
collection statistics synchronization, you'll get a way of synchronizing 
Nepomuk and SQL collection for free, which will be good for users 
transitioning betweem Nepomuk and SQL collections.

I would reword a few paragraphs of the technical details though:
> The core of the project is to implement a NepomukCollection and
> NepomukQueryMaker classes. The classes to handle the generated and indexed
> metadata will be needed as well, eg a handler to write data back to Nepomuk,
> to update the UI using the metadata from Nepomuk index etc.

These will be probably the Meta::{Track,Album,Artist,Year,Genre} subclasses. 
Updating the GUI is done through their notifyObservers() methods and through 
Collection's updated() signal for bigger changes. (But I agree that you may 
want to have sime kind of Nepomuk helper class; something can go directly into 
NepomukCollection though)

Also please note that the Meta::Track interaction with other Meta::
{Album,Artist,...} classes and Collection is a bit tricky to figure out:
 1) if 2 tracks have same album (artist, ...), their album() (artist(), ...) 
methods should return the exact same Album object.
 2) There is a kind of a double link between Track and Album (Artist, ...) 
classes: Track has album() and Album has tracks(). Given that all Meta classes 
are memory-managed using reference counting trough KSharedPtr, you cannot 
simply store a pointer to Album in Track and a list of track pointers in 
Album, because that would essentially create a memory leak. But thanks to 
Nepomuk, you might not face this problem. (for some inspiration how this is 
solved in UMS and iPod Collections, you may have a look at src/core-
impl/collections/support/MemoryMeta.{h,cpp};)
 3) While undocumented, all Meta classes' methods should be thread-safe 
(Collection's need not)
 4) Lifetime of a Meta class object is out of your control. It can happen that 
"their" collection is deleted when they are still alive. This has been the 
source of some crashes in past, so please count with it.

I'm confident you'll be able to get through this, I just wanted to point out 
some things in advance that I faced when re-writing IpodCollection.

> The NepomukQueryMaker can be developed into an API which can be used by
> plugin developers to exploit the Nepomuk backend.

Hmm, I think it would be suboptimal to add plugin API just to 
NepomukQueryMaker, better add it to the generic QueryMaker, so it will work 
for all subclasses. But this feature should be IMO very low priority, this can 
be easily done after the GSoC.

> The existing database schema will be followed so as to not break the
> existing applications and plugins. So, the propagation to a Nepomuk backend
> would be seamless.

Hmm, I think I know what you wanted to say here, but "database schema" is an 
implementation detail of the SQL collection. Perhaps you can say something 
like "Existing design of Meta classes [1] will be followed"..

[1] http://amarok.kde.org/wiki/Development/Architecture

Cheers,
			Matěj