GSoC draft application

Tue Apr 30 12:59:51 UTC 2013

Matej,
Thank-you once again for your comments. I have drastically changed my
proposal based on it. I didn't want you to read my entire application again
so I just comment on some things that I have changed but I'm not so
confident about.
Regards,
Vedant

On Tue, Apr 30, 2013 at 2:11 AM, Matěj Laitl <matej at laitl.cz> wrote:
>
>
>
 >    Each TagGetter::Provider will have its own directory under the
> TagGetter
> >    directory. They will contain classes and one that will implement the
> >    Provider class. Data will be shared among the classes (in the
> TagGetter
> >    namespace) probably via QExplicitlySharedDataPointer.
>
> what data?
>
> I will share Provider pointers (and some other pointers) among different
classes (like the classes handling GUI will require information from the
provider) via the QExplicitlySharedDataPointer.

> > A AbstractSettings class will also
> > be present so that users can customize the settings of each Provider and
> > each Provider can store a small amount of data in the data using the
> > KGlobal::config(). This will also be beneficial for the programmer(s) who
> > add more Providers. It will also keep a consistent look and feel of all
> the
> > TagGetterProviders.
>
> Hmmm, the original intent was to make the providers rather dumb and almost
> invisible to the user. What do you think would be need to be configurable
> by
> the user?

Each Provider can store a small amount of data in the data using the
KGlobal::config(). A provider should add itself to the "plugins" section in
Amarok Settings so that it can be enabled/disabled by the user. If badly
required also provide some additional user changeable settings, since its
best to keep working of plugins as abstracted from the user as possible.

> > Other code will also be re-written but its work
>  > will mainly remain the same, except for one major difference. Currently,
> > libofa is used to create the MusicIP (PUID) that is sent to MusicBrainz.
> > MusicBrainz is phasing out PUIDs in favour of AcustIDs.
> >
> >    Hence, the MusicBrainzProvide will use
> > Chromaprint<http://acoustid.org/chromaprint>to compute AcustIDs rather
> > than the MusicIP generated by libofa.
>
> Oh beware! The musizbrainz and musicip are rather independent and were
> intended to be factored out into 2 separate providers! (one changing to
> acoustid)
>
The MusicBrainzFinder will become MusicIpProvider, implementing the
abstract Provider class. Other code will also be re-written. Currently,
libofa is used to create the MusicIP (PUID) that is sent to MusicBrainz.
MusicBrainz is phasing out PUIDs in favour of AcustIDs.

Hence, another Provider will be made (in the same directory).

>
> > Codecs will identified using ffmpeg.
>
> What/why?
>

<line deleted>

>
> > Phonon will be used for decoding while Chromaprint will be used to
> generate
> > the AcoustID.
>
> Have you checked this is possible? What Phonon methods will you use?
>
> Chromaprint will be used to generate the AcoustID. <rest deleted>

> > Chromaprint uses the
> >    standard C
> > library[*]<
> https://bitbucket.org/acoustid/chromaprint/src/master/src/chroma
> > print.h>so using this won’t be a problem.
>
> Eh? What is a connection between a project using a standard C library and
> feasibility of its usage?
>
Chromaprint uses the standard C
library[*]<https://bitbucket.org/acoustid/chromaprint/src/master/src/chromaprint.h>so
code can easily embedded.

> Vedant, I really think that implementing all the stuff you've outlined is
> unachievable, at least not in a code quality we'd expect. Please take some
> time to significantly reduce the amount of work you plan to do. Many of the
> ideas you have on top of the idea (published by devs) simply don't align
> with
> Amarok goals and/or are based on misunderstanding of how current tag
> guessing
> works.
>
I have corrected the above after running amarok with Alberto's patch and
seen how current tag guessing works.
I entirely removed the "better GUI" and "tag-getter wizard" points
completely and hence other occurances of the same.

>
> > Other Obligations: I have no other obligations. I can easily spent about
> 50
> > hours a week: around 8 hrs a day in slots of 2 to 3 hrs, one each in the
> > afternoon (10am-1pm), evening (4pm-6pm) and at night (10pm-1am), with
> some
> > hours less on weekends.
>
> Hehe, I don't think you need to be this detailed. :-)
>
> I thought i should mention times due to metor-student time zone
difference. Anyway I have changed it to: I have no other obligations. I can
easily spent about 50 hours a week: around 8 hrs a day in slots of 2 to 3
hrs.

> > Summer vacations will be going on till mid July.
> > Even after college starts, I will be following the same schedule for GSoC
> > coding. It is easily possible because very few classes are held in the
> > beginning of the semester and even if they do clash with my coding
> > time-period, the college teachers excuse GSoC students' absence from
> class.
> > Since I will have no other coursework obligations, I can continue to code
> > 50 hours a week (with a similar schedule) even up till September.
> >
> > About Me: I am currently in my second undergraduate year in National
> > Institute of Technology, Durgapur, India, studying Computer Science and
> > Engineering. I have experience coding experience with C/C++, Java
> > (including Android and making GUI using Java swing) and web services. I
> > have submitted 3 patches (Junior Jobs, one each for
> > Rekonq[1]<https://git.reviewboard.kde.org/r/107662/>and Amarok
> > [2] <https://git.reviewboard.kde.org/r/109283/> as well as a improved
> > formatting patch for Amarok[3] <
> https://git.reviewboard.kde.org/r/109295/>)
> > and 2 more are under review (both Junior Jobs for
> > Amarok[4]<https://git.reviewboard.kde.org/r/110101/>
> > [5] <https://git.reviewboard.kde.org/r/110082/>).
> >
> > I love coding for open source. I’m sure working with a mentor who is
> > virtually present won’t be a problem. I have interacted (mainly with
> Matej
> > a.k.a. Strohel on IRC) over IRC, the amarok mailing list, reviewboard and
> > also the KDE bug tracking system. During the work period code can easily
> be
> > shared via GitHub.
>
> We prefer personal scratch git repositories on KDE infrastructure for this.
>
> > If it is possible, meeting a mentor face to face will
> > obviously be much more helpful. I have worked with my college seniors in
> > this fashion who have introduced me to Linux and Open-Source. Countless
> > times I have been to their rooms for advice and to solve my problems.
> >
> > After GSoC I plan to become an active developer for Amarok and also for
> > other projects of KDE.
>
> As stated above, this looks to me like a way too much work to do. Perhaps
> you
> are trying to make the proposal more interesting, but I fear that the
> effect is
> the opposite - we'd actually appreciate if you wanted to implement much
> less
> things (ideally just what the initial idea was about), but make it
> interesting
> by level of insight, research and thought that has been put to it.
>
> Also please study/use the current tag guessing in Amarok more (and do have
> a
> look at Alberto's patch) to avoid a situation where you describe lack of
> Amarok feature while it is not the case.
>
> Regards,
>                 Matěj
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20130430/5036a810/attachment-0001.html>