zeenix
commented
3 years ago While property caching provides this behavior, it is currently not obvious (at a type level) if this is enabled, nor is it documented that having caching enabled results in reads always making no round-trips.
Don't think it needs to be encoded in the type system. Just because something is async, doesn't imply a guaranteed I/O operation. However, we can certainly improve the docs to make the caching part super obvious.
Ideally I would like a sync interface (that is, one which does not internally call
block_on)
I'm not sure I want more API to work-around a general Rust async/await problem. If you want to read the property in an async context, use async proxies; otherwise just use the sync one that use block_on.
However, if I could be convinced on the need for providing such API, I think your suggested solution sounds good.
This should be doable by changing the Mutex on the property cache to a
std::sync::Mutex(or rwlock)
As I wrote on the Matrix recently, I think that probably makes sense anyway.
In GitLab by @danieldg on Aug 1, 2021, 17:10
It is useful to be able to read the properties of an object in contexts where you cannot incur the delay of a round-trip to the remote party providing the object (for example, while rendering graphics). While property caching provides this behavior, it is currently not obvious (at a type level) if this is enabled, nor is it documented that having caching enabled results in reads always making no round-trips.
Ideally I would like a sync interface (that is, one which does not internally call
block_on) that gets a (possibly outdated) value of a cached property. An error likePropertyNotCachedcould be used to denote that the async or blocking interface must be used (which would presumably need to actually make a call the remote party).This should be doable by changing the Mutex on the property cache to a
std::sync::Mutex(or rwlock) and, if needed, having a separate asyncMutexact as a write-lock if you need to serialize changes (though I do not see a need for this - updates are delivered as aMessageand don't need any async functions to parse and update).Current high-level API thoughts: keep
async fn property(&self)for the existing behavior and allow addingfn cached_property(&self)for the cached version? It looks likeset_as a prefix is already reserved;cached_could do the same, or it could be an attribute like#[dbus_proxy(property,cached)]if you think dbus properties calledCachedFooare more common than ones calledSetFoo. Obviously only a getter can be cached.