<br><br><div class="gmail_quote">On Sat, Mar 24, 2012 at 3:25 PM, Matěj Laitl <span dir="ltr"><<a href="mailto:matej@laitl.cz">matej@laitl.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2012-03-22, Phalgun Guduthur <<a href="mailto:phalgun.guduthur@gmail.com">phalgun.guduthur@gmail.com</a>> wrote:<br>
> I have been working towards the 2012 GSoC idea 'Semantic Collection for<br>
> Amarok' since a month now. I have already sent in my first rough draft of<br>
> the proposal.<br>
><br>
> At that time, I promised a proof of Concept and you can it submitted on the<br>
> review board <a href="https://git.reviewboard.kde.org/r/104369/" target="_blank">https://git.reviewboard.kde.org/r/104369/</a><br>
><br>
> It is a small patch demonstrating the read and write of Nepomuk index<br>
> through Amarok.<br>
<br>
</div>I was very positively surprised how simple the patch is, good!<br>
<div class="im"><br>
> I have also attached my improvised proposal after interactions with both<br>
> the mentors Teo and Vishesh.<br>
><br>
> Please review my proposal whenever you find time. Any feedback is<br>
> appreciated.<br>
<br>
</div>Hey, the proposal is very good. If I have a chance to implement the inter-<br>
collection statistics synchronization, you'll get a way of synchronizing<br>
Nepomuk and SQL collection for free, which will be good for users<br>
transitioning betweem Nepomuk and SQL collections.<br></blockquote><div> </div><div>That's great! Seamless transition for users is something I highly prioritize, I would love to use your work for this. </div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would reword a few paragraphs of the technical details though:<br>
> The core of the project is to implement a NepomukCollection and<br>
> NepomukQueryMaker classes. The classes to handle the generated and indexed<br>
> metadata will be needed as well, eg a handler to write data back to Nepomuk,<br>
> to update the UI using the metadata from Nepomuk index etc.<br>
<br>
These will be probably the Meta::{Track,Album,Artist,Year,Genre} subclasses.<br>
Updating the GUI is done through their notifyObservers() methods and through<br>
Collection's updated() signal for bigger changes. (But I agree that you may<br>
want to have sime kind of Nepomuk helper class; something can go directly into<br>
NepomukCollection though)<br></blockquote><div><br></div><div>Noted. Will make the necessary changes. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also please note that the Meta::Track interaction with other Meta::<br>
{Album,Artist,...} classes and Collection is a bit tricky to figure out:<br>
1) if 2 tracks have same album (artist, ...), their album() (artist(), ...)<br>
methods should return the exact same Album object.<br>
2) There is a kind of a double link between Track and Album (Artist, ...)<br>
classes: Track has album() and Album has tracks(). Given that all Meta classes<br>
are memory-managed using reference counting trough KSharedPtr, you cannot<br>
simply store a pointer to Album in Track and a list of track pointers in<br>
Album, because that would essentially create a memory leak. But thanks to<br>
Nepomuk, you might not face this problem. (for some inspiration how this is<br>
solved in UMS and iPod Collections, you may have a look at src/core-<br>
impl/collections/support/MemoryMeta.{h,cpp};)<br>
3) While undocumented, all Meta classes' methods should be thread-safe<br>
(Collection's need not)<br>
4) Lifetime of a Meta class object is out of your control. It can happen that<br>
"their" collection is deleted when they are still alive. This has been the<br>
source of some crashes in past, so please count with it.<br>
<br>
I'm confident you'll be able to get through this, I just wanted to point out<br>
some things in advance that I faced when re-writing IpodCollection.<br>
<br>
> The NepomukQueryMaker can be developed into an API which can be used by<br>
> plugin developers to exploit the Nepomuk backend.<br>
<br>
Hmm, I think it would be suboptimal to add plugin API just to<br>
NepomukQueryMaker, better add it to the generic QueryMaker, so it will work<br>
for all subclasses. But this feature should be IMO very low priority, this can<br>
be easily done after the GSoC.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> The existing database schema will be followed so as to not break the<br>
> existing applications and plugins. So, the propagation to a Nepomuk backend<br>
> would be seamless.<br>
<br>
Hmm, I think I know what you wanted to say here, but "database schema" is an<br>
implementation detail of the SQL collection. Perhaps you can say something<br>
like "Existing design of Meta classes [1] will be followed"..<br>
<br></blockquote><div>Yes that was what I meant, will reword it accordingly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[1] <a href="http://amarok.kde.org/wiki/Development/Architecture" target="_blank">http://amarok.kde.org/wiki/Development/Architecture</a><br>
<br>
Cheers,<br>
Matěj<br>
<br>
_______________________________________________<br>
Amarok-devel mailing list<br>
<a href="mailto:Amarok-devel@kde.org">Amarok-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/amarok-devel" target="_blank">https://mail.kde.org/mailman/listinfo/amarok-devel</a><br>
</blockquote></div><br><div>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. </div>
<div><br></div><div>I will make sure, all the points are noted and taken care of.</div><div><br></div><div>Cheers</div><div>Phalgun</div><div><br></div><div><br></div>