Re: GSoC 2012 : Improvised proposal for 'Semantic Collection for Amarok'
On Mon, Mar 26, 2012 at 23:28, Matěj Laitl wrote: > On 26. 3. 2012 Teo Mrnjavac wrote: >> 2) Can you please be a little more elaborate on why NepomukCollection it >> can't be completed before NepomukQueryMaker? > > What will you return in Collection's queryMaker() method? A collection without > a querymaker is virtually unusable, it won't be shown in Collection browser > etc. > > Matěj > ___ A solitary QueryMaker is good for unit testing though. But internally you might want to put some infrastructure code in the Collection and construct the QM with a Collection-ptr. So yeah, those 2 classes are very much interwoven. ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: GSoC 2012 : Improvised proposal for 'Semantic Collection for Amarok'
On 26. 3. 2012 Teo Mrnjavac wrote: > 2) Can you please be a little more elaborate on why NepomukCollection it > can't be completed before NepomukQueryMaker? What will you return in Collection's queryMaker() method? A collection without a querymaker is virtually unusable, it won't be shown in Collection browser etc. Matěj ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: GSoC 2012 : Improvised proposal for 'Semantic Collection for Amarok'
On Fri, Mar 23, 2012 at 3:26 PM, Teo Mrnjavac wrote: > On Thu, Mar 22, 2012 at 18:25, Phalgun Guduthur > wrote: > > Hello > > > > 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 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. > > > > Thanks > > Phalgun > > Hello, > > When I read "Improvised" I was a bit worried for a moment ;) > Overall the proposal is pretty good. I'd still like it if you could > think about the timeline a bit more. I'm not sure you can complete the > NepomukCollection before the NepomukQueryMaker. A bit more clarity in > the timeline could go a long way in convincing the team that you > understand the problem thoroughly. > > The proof of concept looks good, simple and to the point. > > Cheers, > -- > Teo > Well, there were a few additions in the proposal, hence 'improvised' ;) Just two questions, 1) Is my timeline good w.r.t granularity? Should I be more specific. I'm already worried that my proposal is lengthy. 2) Can you please be a little more elaborate on why NepomukCollection it can't be completed before NepomukQueryMaker? I was afraid the proof of concept would be deemed too simple. Glad you find it good enough. Cheers Phalgun ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: GSoC 2012 : Improvised proposal for 'Semantic Collection for Amarok'
On Mon, Mar 26, 2012 at 16:03, Phalgun Guduthur wrote: > > On Fri, Mar 23, 2012 at 3:26 PM, Teo Mrnjavac wrote: >> >> On Thu, Mar 22, 2012 at 18:25, Phalgun Guduthur >> wrote: >> > Hello >> > >> > 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 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. >> > >> > Thanks >> > Phalgun >> >> Hello, >> >> When I read "Improvised" I was a bit worried for a moment ;) >> Overall the proposal is pretty good. I'd still like it if you could >> think about the timeline a bit more. I'm not sure you can complete the >> NepomukCollection before the NepomukQueryMaker. A bit more clarity in >> the timeline could go a long way in convincing the team that you >> understand the problem thoroughly. >> >> The proof of concept looks good, simple and to the point. >> >> Cheers, >> -- >> Teo > > > Well, there were a few additions in the proposal, hence 'improvised' ;) > > Just two questions, > > 1) Is my timeline good w.r.t granularity? Should I be more specific. I'm > already worried that my proposal is lengthy. > > 2) Can you please be a little more elaborate on why NepomukCollection it > can't be completed before NepomukQueryMaker? The NepomukCollection isn't very useful by itself without a QueryMaker. Of course you can do one and then the other but I figure it would be much easier to test if you do it at the same time. This was pretty much my only concern. Cheers, -- Teo ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: GSoC 2012 : Improvised proposal for 'Semantic Collection for Amarok'
On Sat, Mar 24, 2012 at 3:25 PM, Matěj Laitl wrote:
> On 2012-03-22, Phalgun Guduthur 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.or
Re: GSoC 2012 : Improvised proposal for 'Semantic Collection for Amarok'
On 2012-03-22, Phalgun Guduthur 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
___
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
Re: GSoC 2012 : Improvised proposal for 'Semantic Collection for Amarok'
On Thu, Mar 22, 2012 at 18:25, Phalgun Guduthur wrote: > Hello > > 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 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. > > Thanks > Phalgun Hello, When I read "Improvised" I was a bit worried for a moment ;) Overall the proposal is pretty good. I'd still like it if you could think about the timeline a bit more. I'm not sure you can complete the NepomukCollection before the NepomukQueryMaker. A bit more clarity in the timeline could go a long way in convincing the team that you understand the problem thoroughly. The proof of concept looks good, simple and to the point. Cheers, -- Teo ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
