Fwd: extragear/multimedia/amarok/src/servicebrowser/lastfm

[Nikolaj Hald Nielsen]

I am forwarding a bunch of mails that I accidentally made private. Max
has signed off on this.

First one:

---------- Forwarded message ----------
From: Nikolaj Hald Nielsen <nhnfreespirit at gmail.com>
Date: Mon, Mar 3, 2008 at 12:24 PM
Subject: Re: extragear/multimedia/amarok/src/servicebrowser/lastfm
To: maximilian.kossick at gmail.com


On Mon, Mar 3, 2008 at 9:52 AM, Maximilian Kossick
 <maximilian.kossick at googlemail.com> wrote:
 > The idea of the collection framework and in particular the Meta
 >  framework [1] is to hide the implementation details of the music from
 >  other core components like the playlist or the engine. I just had a
 >  look at the shoutcast service again, and it looks like the "expand
 >  track" capability that we talked about a while ago never actually was
 >  implemented as far as i can tell. So forget what I was saying about
 >  the shoutcast service.

 Yes, it actually is, to the extend that each tracks url is checked for
 whether it is actually a playlist type. Really ugly hack imo. but at
 least it works. For now....


 > That capability would create a problem though.
 >  What we would essentially be doing, if we'd actually use that or a
 >  similar capability, is to make other parts of Amarok aware of
 >  implementation details of that collection/Meta implementation, even if
 >  we slap another abstraction layer on top of those implementation
 >  details. Doing that would require special code to handle those
 >  details, which results in additional if/else statements (and I really
 >  dislike if/eslse statements if they can be replaced by a proper
 >  architecture). This can be avoided by keeping the implementation
 >  details internal to the component where the tracks are originating
 >  from.

 As I see it, right now a huge bunch of if/else statements is exactly
 what you are getting. Adding playlists to the playlist mode currently
 requires a set of completely separate functions that basically just
 replicate the stuff that is in the 'normal' insert methods.


 >  If we ignore the question whether a tree view is really the right user
 >  interface for last.fm, making last.fm a collection and reusing the
 >  collection view create a few problems. I don't know what you layout
 >  you have in mind for that tree, but at the very least we'd have
 >  something similar to global tags in A1, so we'd need a Global Tags
 >  node which would have a child node for each global tag. The problem is
 >  that the Global Tag node is not a real node[2]. For example, adding
 >  all child nodes of the Global Tags node to the playlist does not
 >  really make sense from a UI POV, although it's technically possible.

 Why shouldn't be allowed to add a group of streams to the playlist?
 For now, the last.fm "skip" and playlist "next" actions are separate
 anyway, so the user can both skip within a stream and forward to the
 next one. I agree that it is not something I would use, but I don't
 see why it conceptually does not make sense. To be honest, I never
 planned to take over the last.fm service, I jsut saw what Hydrogen had
 done and figure that it could be added to the treeview really easily (
 which I still think it can, even though we once again bang our head
 against the "this is a stream pretending to be a track" issue. If this
 is the correct user interface for the last.fm service I have no idea,
 and luckily his is not for me alone to decide! :-)


 >  Removing that item from the context view would mean modifications to
 >  the collection view and/or the model, and we all know that these two
 >  classes unfortunately contain lots of black magic. Then there's the
 >  problem how we'd insert the Global Tags node into the collection view
 >  anyway? Using another Meta class to fake it, e.g. Meta::Genre, results
 >  in each track having the genre "Global Tags".

 Yes, and why is that bad? It is as good as any other genre description
 we could come up with. In the shoutcast service, this means that a
 stream has the genre of the category it was in ( for instance,
 "Hardcore Rock", or "Albanian" ) which again imo is a good as any
 other genre we can give it. ( Technically this does not currently work
 because of having to generate a new playlist out of the track, thus
 loosing the genre data... )


 >  And I am completely
 >  against extending the CollectionModel with support for further "fake"
 >  nodes. Adding Various Artists was bad enough, and we don't have to try
 >  and break it again.

 Yes, you have gotten that point across loud and clear by now. If I
 were to put things on edge just a little bit, I would say that I get
 the feeling that you are strongly opposed to adding anything to the
 collection framework that was not part of your original grand scheme.
 The downside of this is that it leaves the rest of us who are doing
 things _slightly_ outside the bounds of the uses you had originally
 thought out to "go play in a corner somewhere" and basically
 reimplementing features from the collection framework just to get even
 fairly basic stuff like playlists working in a sane way.

 Additionally, I don't think we need more fake nodes. Make streams and
 playlists proper members and most of these issues will go away. I see
 no reason that a stream or playlist should not be allowed to have a
 genre or other meta data the same as every other playable item.


 >  I am sure that we won't end up with 20 similar models/views if we
 >  approach this problem properly btw:)

 No, but still having ( basically ) the same code twice already gives
 me a bad taste in my mouth.

 I am really not trying to be inflammatory here, but I do feel very
 strongly about this, and I do feel that we are creating an A and a B
 team of content instead of being able to integrate whatever we come up
 with seamlessly, which really for me is the main feature of A2. This
 is besides the fact that it will make the service framework mostly
 useless for many types of content as you are basically going to have
 to write everything from scratch anyway.

 - Nikolaj