Merging of Tomahawk-Integration into Amarok-Master

[Lucas Lira Gomes]

Hey,

I'm doing well to some extent. Thanks to ask. Hope you're well too.

But, unfortunately, I must say that I do not intend to integrate
libtomahawk with Amarok anymore. Please, don't get me wrong. I'm not saying
that all my GSoC work was in vain and that the confidence that everyone had
in me was an error. In fact, I have been trying to separate libtomahawk
from the rest of the Tomahawk code until the end of January. However,
simple changes were demanding a huge effort. All that just to separate,
because we still had to do a Macgyver on the database stuff. Having another
database running just because a plugin required that is somewhat difficult
to accept in the long run. All that made me feel really frustrated for a
while, since I haven't met my expectations neither in Tomahawk nor in
Amarok.

Going awol was probably a consequence of that problem. And the fact that I
care about both communities made this situation bother me even more. So,
after doing some serious thinking in January, I decided that integrating
libtomahawk wasn't the right thing to do. I couldn't know at the very
beginning of my GSoC how that would end and that obviously was a tough
decision to make.

Tomahawk is really full of great ideas and I completely understand why
everybody insisted on the idea of using its code, since making everything
from the scratch must be always our last card to play. Seriously, I'd
learned a lot with all the design choices that were made. Resolvers, the
protocol itself, the way that XMPP and its XEPs were used for peer
discovery were simply outstanding ideas.

But fear not, as a consequence of everything aforementioned I started to
develop a new library, even though I knew that Domme was against this
alternative, to do everything that was planned during my GSoC. I call it
TPLib, but maybe I should change its name for something that resembles more
its social features afterwards. In spite of that, I guess many of you are
now asking yourselves why I haven't told anybody about that yet. Well,
people tend to accept an ongoing work easier than just promises, as both
Andy Hunt and David Thomas wisely pointed out in the Pragmatic Programmer.

And speaking of that, I believe that I owe everyone apologies. Especially,
for you Domme. Your commitment as a mentor was exceptional. Your several
emails, even after GSoC are a concrete proof of this. Tomahawk team, in my
opinion, should be really proud of having a contributor with such great
sense of community.

To be honest, I still need at least three months for having it working as
desired for a first release. Despite that, I've made all the stuff related
to sources management, control connection, database sync connection and I'm
polishing the stream connection stuff right now. Although the three
connection types were almost done, I'm focusing on getting the part of
having access to peers collections first. Along with units tests to
validate my work. Right now, for instance, the library has something about
7000 lines of code, regardless of cmakelists and non-c++/qt related files.

With the the stream connection stuff done, I can then concentrate on the
Amarok side for a while. Trying to listen to other peers collections. But
that's only half of the equation. Since I still have to make others able to
listen to TPLib users' collections and integrate that on Amarok. That's all
I need to do before deploying this work on Amarok.

Playlists are out of question at this first moment. Since, in most cases,
I've noticed that users tend to add much more tracks from resolvers plugins
than from their own collections. Therefore, I believe we should postpone
playlists to a second release of TPLib.

On balance, here goes a quick tour on what was planned/done:

Part 1:

Create separate message processors for every kind of connection [DONE]
Create separate message factories for every kind of connection [DONE]
Manage new peers incoming network connections [DONE]
Manage control connections [DONE]
Make unit tests for control connection related classes [TODO]
Create classes to process database commands, converting from json and vice
versa [DONE]
Make unit tests for database commands related classes [DONE]
Manage database connections [DONE]
Make unit tests for database connection related classes [TODO]
Manage stream connections [DOING]
Make unit tests for stream connection related classes [TODO]
Add support for sip plugins (Zeroconf, Gmail and Jabber) [TODO]
Integrate TPLib with Amarok and listen to others collections [TODO]

Part 2:

Make others able to get TPLib users' database state [TODO]
Make others able to listen to TPLib users' collections [TODO]
Add support to listen along and what you're listening features [TODO]
Add support for Tomahawk resolvers [TODO]
Add static playlist support [TODO]
Add dynamic playlist support [TODO]

Apart from technicalities, I'm really enjoying the whole experience of
building up a library from scratch. Up to now this has lead me to several
improvements in my coding skills; from tests to API design. In a way that,
TPLib will be a reflect of everything that these 2 years of floss and
patient friends had taught me.

Last but not least, I don't know if someone from our team still want to
integrate tomahawklib with Amarok after all that was said in this email.
Especially now that another GSoC is beginning. Otherwise, I can help
clarifying what I had done.

TPLib repository: www.bitbucket.org/x8lucas8x/tplib

Regards, Lucas Lira Gomes.

----------------------------------------------------------------------------------
Lucas Lira Gomes (llg)
Linux User #533002
Tel.: (81) 9235-0916

www.about.me/lucasliragomes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20130329/f618875e/attachment.html>