| sitter |
kcddb is basically a musicbrainz frontend now
| No Linters Available |
| No Unit Test Coverage |
| Buildable 23598 | |
| Build 23616: arc lint + arc unit |
@rstephenson adding you as tellico person, as far as i know this still leaves the API used by tellico
Heiko, added you ask audex person, i think i have not removed any of the API used by audex either
Looks reasonable.
Do you think it'd make sense to mark the remaining classes deprecated? If the long term goal is to drop the lib entirely and have people use musicbrainz directly I figure we should communicate that.
| CMakeLists.txt | ||
|---|---|---|
| 20 ↗ | (On Diff #77380) | Could be moved to auto-managed versions I guess? |
It still uses KCDDB::Config(), KCDDB::Client::config() and KCDDB::Client::submit(), which are all gone.
k3b also breaks due to Client::store(). audiocd-kio doesn't build either, but it looks like it's only missing a few includes.
I assume you want to get this in until tomorrow night to avoid bug reports about CD lookup not working?
| CMakeLists.txt | ||
|---|---|---|
| 20 ↗ | (On Diff #77380) | It's not used for anything at all, i'll just remove it. |
I agree and disagree :)
I think libkcddb needs to die, since it's basically built around the cddb service which is shutting down, i mean the musicbrainz support was optional until this change.
Otherwise I'm not sure if suggesting people to use libmusicbrainz directly is the best idea and maybe we need something intermediate? I mean if you look at MusicBrainzLookup::calculateDiscId that's something i wouldn't want everyone to have to implement themselves
Right, submit needs to be gone, there's nowhere to submit once freedb.org is gone. As for config() there's no config now, so you would need to just remove those calls too.
k3b also breaks due to Client::store().
What k3b here is doing is saving to the "kcddb cache" which i removed because i thought noone is using it, now we could add it back, but i'd rather not and lose that "feature" for 3 reasons:
audiocd-kio doesn't build either, but it looks like it's only missing a few includes.
I assume you want to get this in until tomorrow night to avoid bug reports about CD lookup not working?
Yeah, i mean being part of the release service it *could* wait until next week since we know the thing is going to be released which is one of the reasons for the dependency freeze to be a week before the actual release (make sure your dependencies are released and in place).
FWIW at least in Debian the users of libkcddb are:
The first two were already mentioned here; can you please try to build also soundkonverter and tellico with the proposed changes? Thanks.
I had a look at them yesterday already, they don't seem like they would suffer specially (though they may stop compiling, this is a API breaking change, hence the soname increase)
Thanks for tagging me. I've got a working patch for Tellico against this since I do use KCDDB::Config for cache locations.
AIUI, gnudb.org will still be available though, and should be compatible to freedb.org.
http://www.gnudb.org/howto.php
Fair point. Writing an intermediate library is extra work that I fear will not happen unless there's reason to, so my thinking was having kcddb deprecated so it annoys one of the developers that use it into making libqmusicbrainz as a replacement ;). Scratching their own itch, as it were.
+1 to the diff though. In particular also +1 to the dependency change, it could be landed on its own to at least get that in before dep freeze.
Have you seen the comment
So no gnudb.org?
Also, why would a central cache an alien concept when we have the same for thumbnails?
To clarify: the options as I understand them are:
a) use gnudb instead of freedb (which wouldn't require any API change?)
or
b) use musicbrainz exclusively (the diff at hand)
Under the assumption that we want to have b), the diff looks fine to me. I have no particular objections to going with a) either, in which case this diff I guess would be moot in general. I'll leave that for someone else to decide, I have no horse in the game here and thus have no feelings one way or the other.
I would however argue for b). Subjectively I'd say there are much fewer users of CDs in general and even fewer dealing with CDs on computers which does call into question whether we should support two backing info-lookup systems considering there's twice the amount of code to bit rot and twice the amount of testing that technically would need doing for changes (not that there are changes ^^). Under that view point shrinking the library seems like a very reasonable thing to do and going with musicbrainz is probably the better choice as there seems to be more interest for it (and thus more/better data one presumes) than for freedb/gnudb. According to google trends anyway.
I've decided to just switch over to gnudb.org for now
https://commits.kde.org/libkcddb/36c233672e252132db78dfad4c9ec527eef9741a
It's a less dramatic change and so we don't need to rush this over the last days of the freeze.
But anyway we know that if we ever want to kill the cddb support the code is already done & reviewed :)
Under that view point shrinking the library seems like a very reasonable thing to do and going with musicbrainz is probably the better choice as there seems to be more interest for it (and thus more/better data one presumes) than for freedb/gnudb. According to google trends anyway.
But who guarantees that musicbrainz is here to stay and not being discontinued at one point in the future, like it happened to freedb now?
At least gnudb.org apparently was created to avoid such problems.
And that's actually a point to keep libkcddb anyway IMHO, so that not every single application (that uses it) has to deal with these issues.
My 2 cents only though, of course.