Merging of Tomahawk-Integration into Amarok-Master

[Lucas Lira Gomes]

Hey,

...

 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.
>>
>
> To be honest that really disappoints me:
>
> I had always kept telling you that I was more than happy to help make
> libtomahawk a proper usable library and to work on that myself as well.
> I know you had to fight the database stuff a lot. I see that one can
> dislike the second database.. STILL I'm convinced we were very open to
> compromises and offered/asked you *several* times to discuss what you're up
> to - in fact - I demanded you to talk more to me/us during GSoC ... you
> promised to do so in future and now once again you've been fiddling around
> on your own for months without discussion. I'm pretty sure if you told us
> that the second database approach certainly doesn't work you, we would have
> found a solution together...
>

My apologies. Failure to communicate was my biggest mistake. I'm aware of
that, but I can't step back in time.

Furthermore we told you that using the second database should be the first
> temporary step, so we can make sure everything is basically working first
> and you don't start with the most error prone part ...


Actually, the database stuff isn't the only problem. More severe ones are
described bellow.

...

 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.
>>
>
> ... and I'm still sure it's a terrible idea to reimplement all of this.


Well, I'm obliged to disagree. But, again, I respect your opinion.


>  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.
>>
>
> As much as I'm against this in the long run, maybe it will help us
> determine where the problems in the libtomahawk API are and make it usable
> for you at last...


There is always a chance.


>  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.
>>
>
> Thanks, the not so romantic view on this might be:
>
> I was your mentor and let you pass the evaluations, if this doesn't make
> its way upstream I have to justify why ...  maybe not officially but at
> least to myself.


That's not the case. You've misinterpreted the reason why I wrote about you.


>  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.
>>
>
> I would have much preferred, if you merged your already finished work
> first and then worked on improving it (even if it was with your own
> library) ... currently it looks like you just vanished from the face of the
> earth after not completely finishing your project.
>
> <snip>technical details</snip>
>
> Will look at that some time next week after some exam.


Merging my GSoC work and then improve it to make my own library would be
pointless. That's not about having my own library. The point is, TPLib's
design is based not only in libtomahawk features but also in what
libtomahawk is not. Let me clarify that, some time ago I asked lfranchi why
he hadn't implemented these social features in Amarok. He was an amaroker
by the time he had many of the ideas that Tomahawk currently implements.
And he replied that, given Amarok design at that time, that would require a
huge effort. I'm not saying that we should reinvent the wheel as we please
nor that lfranchi or I done the right thing, but given Tomahawk current
design, in my opinion, it would demand too much to be usable by
third-parties in a reasonable manner. I'm not saying it's not doable in the
long run, but it was not made with stuff that most people expect from a
library.

Like testability, for instance, since Tomahawk code doesn't make use of
tests and even if we want then its many singletons would made the task
almost impossible. On the other hand, it make use of assertive programming.
It's is a good idea, but I believe that an automated approach is far better
than expecting a run-time error to happen. There is also about three
library dependencies which are not optional in its API, but that's not a
big deal. Other problems that afflict Tomahawk are coupling and low
cohesion, in part because of the many singletons, which makes the whole
code much more difficult to reuse, maintain and understand.

It's also noteworthy the fact that it uses a lot of compiler directives to
enable/disable gui related stuff. Although this is a problem per se, the
fact that these directives are even in classes that implements the logic of
libtomahawk, which should be gui independent, is very troublesome.

One can say that everything had always worked in Tomahawk that way. Indeed
it works. However, in my opinion, it would be risky to create a library
based on code with these problems. That's why I'm writing a new one from
scratch.

...

>  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.
>>
>
> I doubt anyone (including me) would want to see another
> Tomahawk-Amarok-GSoC-project right now for understandable reasons.. :-P
>

Understood.


> We (I'm speaking for the team here) are still convinced that using
> libtomahawk is the much better approach:
> 1) it will help you because you don't need to try to catch up with our
> development.
> 2) it will help us improve our library for external usage.
>

Good points, but number one isn't a big problem. Tomahawk network protocol
would be basically the only interface between TPLib and libtomahawk and,
fortunately, it doesn't seems to change often. Also, sip plugins code could
be used by us with only a few modifications here and there (mainly removing
gui stuff). These are the only two things that can force me to catch up
with Tomahawk development.


> Even if you go for your own library _we're still happy to cooperate_, but
> seriously - for one last time - you need to talk to us. Please show up on
> IRC from time to time or at least drop a line to welisten@, tell us what
> you're up to - otherwise we can't support or care for your library...
>

Sure, I'll drop in Tomahawk channel on Monday. I'm currently in my parents
house and I find really annoying to chat without a keyboard (I'm writing
this email via a tablet). And thanks for offering your help even after all
that.

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/20130330/1aad5f99/attachment-0001.html>