Allow dbus_interface property getters to return errors

[zeenix]

Seems this is needed by some projects.

[zeenix]

In GitLab by @szclsya on May 30, 2022, 06:58

Hi, I'm currently having difficulties designing getter interfaces that are failable. Is there any progress on this problem?

[zeenix]

Hi Leo, I'm afriad I've not gotten around to fixing this but knowing that now there is one more person who needs this, I'll try and prioritize this over thing things.

In the meantime, you can use D-Bus method as getter until this if addressed.

[zeenix]

In the meantime, you can use D-Bus method as getter until this if addressed.

This is not too bad of a workaround actually. I've seen many services providing getter methods for properties.

[zeenix]

In GitLab by @szclsya on May 30, 2022, 21:09

Thanks for the advice. Unfortunately I'm actually trying to write an implementation for an already established specification, so I have to implement it using property. I guess I'll just return an empty response and write some logs to report the issue then.

Other than that, thank you (and other devs too) for your work on this project!

[zeenix]

Thanks for the advice. Unfortunately I'm actually trying to write an implementation for an already established specification, so I have to implement it using property.

Ah ok, gotcha.

I guess I'll just return an empty response and write some logs to report the issue then.

I guess. :shrug: tbh, it's a bad interface if it needs fallible properties. If you have an interface exposed on a path, its properties should all be there. If you need fallible properties, most likely the interface designer didn't split the interfaces properly or didn't think about interfaces as dynamic.

Other than that, thank you (and other devs too) for your work on this project!

you're welcome!

[zeenix]

In GitLab by @Alxandr on Oct 8, 2022, 14:05

If you have an interface exposed on a path, its properties should all be there.

mpris have multiple properties that per specification may not be present. See for instance https://specifications.freedesktop.org/mpris-spec/latest/Player_Interface.html#Property:LoopStatus.

[zeenix]

If you have an interface exposed on a path, its properties should all be there.

mpris have multiple properties that per specification may not be present. See for instance https://specifications.freedesktop.org/mpris-spec/latest/Player_Interface.html#Property:LoopStatus.

Then it's going against the D-Bus spec. There is a good reason why the spec separate interfaces from object paths and interfaces are dynamic. So the proper solution is to split the api into multiple interfaces and add/remove interfaces on the fly.

Having said that, I know of one other instances where the implementers decided that property can be dynamic so I wouldn't mind solving the issue of optional properties as long as it doesn't complicate api and impl.

Property getters should allow errors anyway (which is what this issue is about) so if that also solves the problem of optional properties, than even better.

[zeenix]

mentioned in commit 3b536f263629c7799973da29c485d63cdd3e4161

[zeenix]

This was resolved by !649.