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

[Phalgun Guduthur]

On Sat, Mar 24, 2012 at 3:25 PM, Matěj Laitl <matej at laitl.cz> wrote:

> 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.
>

That's great! Seamless transition for users is something I
highly prioritize, I would love to use your work for this.


> 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)
>

Noted. Will make the necessary changes.


> 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.
>

Yes, I did not mean to design the NepomukQueryMaker into a separate plugin
either, It will be added to the generic QueryMaker. Will be more explicit
on this in the proposal.


>
> > 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"..
>
> Yes that was what I meant, will reword it accordingly.


> [1] http://amarok.kde.org/wiki/Development/Architecture
>
> Cheers,
>                        Matěj
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>

Finally, thanks for the generous reply and heads up. Truly appreciate it. A
lot of technical details to consider has been put forth. I'd have taken a
lot of time, if I had to explore all this on my own. I love how willing
this community is in pitching in.

I will make sure, all the points are noted and taken care of.

Cheers
Phalgun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20120325/cee9fa66/attachment.html>