[Amarok] b0503f5 Move Playlists back into Meta.

Bart Cerneels bart.cerneels at kde.org
Sun Mar 28 20:06:05 CEST 2010


On Sun, Mar 28, 2010 at 19:38, Jeff Mitchell <mitchell at kde.org> wrote:
> On 03/28/2010 01:00 PM, Bart Cerneels wrote:
>> Let me base this one similarities with Meta::Track.
>
> The fact that you architected playlists around Meta's architecture
> doesn't mean they belong in Meta.
>
>> * They are also made available by a provider (ref. TrackProvider). It
>> can be part of a Collection consisting of a TrackProvider,
>> UserPlaylistProvider and QueryMaker.
>>
>> * have different implementations (Sql, File, UMS),...
>
> Like Collections or Plugins. They don't belong in Meta.
>
>> * Playlist is a fundamental type in the sense of track being the
>> fundamental type that has Album, Artist, Genre, ... as it's fields.
>> Playlist has only has one complex type field: TrackList. All the rest
>> are strings.
>
> Again: so? (Also: if Playlist is a fundamental type, and Meta is a
> fundamental type, this makes even more sense why they belong outside
> Meta, instead of having fundamental types inside fundamental type.)
>
>> * Playlist could be queried on in QueryMaker as a new QueryType. That
>> way we can search for playlists that have tracks with certain albums,
>> artists, Genre, rating, ... in them.
>
> They can't, according to the bits of the conversation you just had with Max.

That discussion went nowhere because Maxx didn't want to understand
the explanation and technical solutions I presented. It's perfectly
possible that I made incorrect assumptions but there was no
explanation where I was wrong. Only think I got was a No and a
restatement of, what I believe to be, incorrect assumptions.

I assume this is another call for Maximilian to correct me or work
with me to improve this.

>
>> I'm sure there are more arguments to be made, but the biggest one is
>> more abstract:
>> Playlists should not be treated as a second class citizen in Amarok by
>> keeping them out of the true hard of amarok's core: Meta and
>> Collection. It's as much a technical issue: Playlists not supported by
>> QueryMaker; as a social one: new collection implementations (MD)
>> lacking a decent PlaylistProvider.
>
> Stop making baseless assumptions. I've never thought of Playlists as a
> "second class citizen" no matter how many times you have made that
> claim. Nor do I know of anyone else feeling this way except for you.

This is not an assumtion, it's a statement of fact. I'm the only one
working on playlists, other peoples implementations are non-functional
and unmaintained. If Collection would have been treated the same way
there would be no track browsing, copying or organizing in amarok.

>
> Maybe instead of saying that the true hearts of Amarok's core are Meta
> and Collection, you should be making statements that the true hearts of
> Amarok's core are Meta, Collection, and Playlists.
>
> In fact, the evidence is against you: in core/ you find not only meta
> and collections, but also playlists, plugins, podcasts, statistics, and
> more.
>
>> Even though 2.3 has gotten some excellent comments there are still
>> very vocal, flat out hostile rejections that are hard to ignore: there
>> is no decent playlists synchronization and some implementations are
>> flat out missing.
>
> And this has what to do with Playlist being in Meta? (NOTHING.)
>
>> Not surprising as there is only one time strapped developer working on
>> this. Since Jeff has already reverted this I'm sure people are not
>> interested in improving this though.
>
> There's only one time strapped developer working on most of the
> different parts of Amarok.
>
> --Jeff
>

Your mail did not contain anything constructive. You should stay out
of this discussion. [1]

[1] http://www.kde.org/code-of-conduct/


More information about the Amarok-devel mailing list