Draft SoK Proposal

[Myriam Schweingruber]

Hi Nitul,

Thanks for your proposal, but I have some doubts about this.

On Mon, Oct 27, 2014 at 8:47 AM, Nitul Datt <nitul1991 at gmail.com> wrote:
> Hi!
One thing which springs to mind is, suppose a user
> wants to store a custom cover. Should that also be stored in the
> filesystem mentioned in the specification or should it be stored at
> the album location itself?

It already does so, why would you change that? Custom covers should
always be stored locally. Changing what is already there is rarely a
good idea without a major reason.

Don't forget, you want to add a feature, not remove one :)

On the other hand: why would this specification be needed? AFAICS this
is a Gnome library, so it would add another dependency, and not a Qt
one either. I am sure there are far better suited tasks for a SoK
project than implementing an external specification.

I would need a very compelling reason to implement this, as it is only
used by Banshee which is hardly a major player. Is it used by other
media players, specifically Qt-based ones? If not, this is really not
worth to spend time on IMHO, I would consider this feature request a
very minor one for the above mentioned reasons.

Also: this is a Junior Job, which is something doable within a week,
hardly a SoK-worthy task .. I would expect any SoK applicant to
actually first solve a Junior Job to show their ability to code and
tackle a larger project like SoK or GSoC. Junior Jobs are classically
something that can be done within a day or two, a week at most, so
https://bugs.kde.org/show_bug.cgi?id=296049 is clearly not suitable
for SoK at all.


There are currently two things I would see good SoK tasks:

1. What is far more needed since quite some time, and what should be a
high priority to implement is the CUE sheet support. You can easily
judge that from the number of open bugs and the high number of votes
for this feature. It is partially implemented, and there is already
some work lying around IIRC. Mind you, the implementation of proper
CUE sheet support for files in the collection (CUE sheets already do
work more or less for tracks not in the collection currently) would
solve all the existing bugs at once, or at least most of them.

I suggest some digging in other Qt-based players who already do
implement CUE sheet support which will certainly yield some insight on
what is done wrong in our code.

2. Another very much needed feature is porting the current Nepomuk
support to Baloo: https://bugs.kde.org/show_bug.cgi?id=336380 There
are links to previous bugs with more information, and the Baloo
specifications are also very helpful in that regard

And finally: please do not copy-paste bug report wording in your
proposal, but write your own one! A good proposal would show that you
have really put some thought into it, not just a tentative timeline to
something you haven't event really looked at at all. Research is
starting before you do a proposal, and the results should show in the
proposal.


Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)