On Sat, Mar 24, 2012 at 3:25 PM, Matěj Laitl <ma...@laitl.cz> wrote:
> On 2012-03-22, Phalgun Guduthur <phalgun.gudut...@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@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
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
