Skip to content

DBus API improvements

There are some things from the DBus interface which have been annoying me lately, specially while working in the tests for GS plugin:

  1. Repeated and undocumented (ssssssttu) tuple in the interface, which represents a package, but is very prone to errors.
  2. Repositories cannot be enabled or disabled, even though internally the server considers the enabled properties and sends it in the ListRepositories method.
  3. There has also been problems with consistency warranties due to the fact that UpgradePackage only accepts a single package. This is covered in Proposal 8

I have been looking into multiple solutions to this problem. Ideally, they could be approved and implemented independently:

Proposal 1

  • Reduce the package signature size. Do we really need things like license and url?

Proposal 2

  • Merge ListUpgradablePackages and ListAvailablePackages into a single method ListPackages. Add an input argument to that method specify the state (upgradable, available, installed) for which packages are requested.

Proposal 3

Merge SearchFileOwner and ListPackageDetails into a single method ListPackageDetails with two input parameters: identifier string and identifierKind enum (unsigned). The identifierKind provides information on how to interpret the identifier, e.g: like a file path or a package name.

Proposal 4

  • Modify ListUpgradablePackages and ListAvailablePackages to return a very reduced subset of the Package serialization. The idea, that calls to these methods will often trigger subsequent calls to ListPackageDetails. This is an alternative solution to Proposal 1. In this case, the signatures of List*Packages and ListPackageDetails become different.

Proposal 5

  • Modify ListPackageDetails and SearchFileOwner to accept and return arrays of packages/identifiers instead of a single package. This could greatly reduce the amount of round-trips which would be needed when requesting information for multiple packages (which at least in GNOME Software seems to be the norm).

Proposal 6

  • Modify package signature to make it extensible. According the DBus API design, the most appropriate way to do it is by using a{sv}. This could be done for all the methods which currently serialize packages. This collides in some way with Proposals 1 and 4.

Proposal 7

  • Figure out some way to avoid sending all the time new_version and old_version. This adds overhead and is unnecessary. Maybe either the a{sv} or some flag to interpret what the version sent in package signature means (current installed version or possible upgrade/downgrade). Alternatively, the kind of method (ListUpgradablePackages or GetPackageDetails) could be used to interpret the meaning of the version sent.

Proposal 8

  • Replace UpgradePackage method with UpgradePackages method which instead of s accepts as. This would allow both a single package and a group of packages to be updated atomically, providing better consistency warranties. This would also be a breakage of the API.

Additional improvements which I haven't been able to clarify in my head, but for which I had some half-crafted thoughts:

  • Export enum types and serialization to C using cbindgen. This probably fixes most of the problems with interface duplication.
  • Rename new_version and old_version in the serialization and other parts of the code for installed_version and new_version or staging_version. Other ideas?
  • Regarding the repositories, might it make sense to change AddRepository and RemoveRepository by ModifyRepository, with enough input arguments that covers all the use-cases? Maybe would it be better to change the ability to add and remove repositories for the ability to enable and disable them?
  • It would be amazing to fetch the "origin" together with the package details. We really miss this to do some fancy stuff with remote selection in GS.

I had thing dangling around for a while, as I hadn't been able to fully organize it in my head. But since @dylanvanassche is starting to work on the GS software stack too, I thought I'd just post it to avoid doubling work if he ends up looking here ;)

Edited by Rasmus Thomsen