GNOME Bugzilla – Bug 724879
Add async calls
Last modified: 2021-05-25 11:25:41 UTC
Currently, all of libmediaart calls are sync, and don't offer async versions even when the library does synchronous I/O underneath. Async calls should be fairly straight forward to implement using GTask.
Not sure I can get this in before the releases are made in the next few weeks - due to the API break :/ But here it is: https://git.gnome.org/browse/libmediaart/log/?h=async-api
ps. API addition is not an API break (if done right), so addition of the async APIs can be done as a minor version increment in semver rules.
There are API changes though. Pretty much every function in libmediaart/extract.h is an ABI break, and media_art_remove() in libmediaart/cache.h I don't think it's necessary for sync calls to take cancellables, that would reduce the API churn.
(In reply to comment #3) > There are API changes though. Pretty much every function in > libmediaart/extract.h is an ABI break, and media_art_remove() in > libmediaart/cache.h > > I don't think it's necessary for sync calls to take cancellables, that would > reduce the API churn. Ok fair enough. Our major number is still 0 so semver allows to use minor version increments for API changes in that exception case. But as I mentioned on the ML: I think as soon as these APIs are ok; we should do a 1.0.0 and use semver: tracker is a component, being used in production, depending on it.
(In reply to comment #4) > Ok fair enough. Our major number is still 0 so semver allows to use minor > version increments for API changes in that exception case. But as I mentioned > on the ML: I think as soon as these APIs are ok; we should do a 1.0.0 and use > semver: tracker is a component, being used in production, depending on it. "semver"? The stuff at semver.org that the author makes you think he invented? Yeah, sonames: https://git.gnome.org/browse/gnome-desktop/tree/configure.ac#n23
(In reply to comment #5) > "semver"? The stuff at semver.org that the author makes you think he invented? yep, that stuff. Don't care much about who claims to have invented it. Just like how the LGPL is usable, is semver usable :) > Yeah, sonames: > https://git.gnome.org/browse/gnome-desktop/tree/configure.ac#n23 Sounds right.
(In reply to comment #3) > There are API changes though. Pretty much every function in > libmediaart/extract.h is an ABI break, and media_art_remove() in > libmediaart/cache.h > > I don't think it's necessary for sync calls to take cancellables, that would > reduce the API churn. Some of those APIs do multiple I/O operations and can block for an unknown time, so it makes sense in a bunch of cases. For example, downloading content or removing multiple (or all) media art. The cancellables also make it easier to hook up to the async operations. (In reply to comment #2) > ps. API addition is not an API break (if done right), so addition of the async > APIs can be done as a minor version increment in semver rules. Pretty much all the API changes, so I think it's unavoidable to break API/ABI.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/libmediaart/-/issues/ Thank you for your understanding and your help.