On Mon, 2015-10-19 at 13:30 +0300, Tanu Kaskinen wrote: > On Mon, 2015-10-19 at 15:19 +0530, Arun Raghavan wrote: > > * I'm inclined to keep the implementation of the relative volume > > calculation server-side, > > If we want a policy module to be able to enforce the behaviour at the > server side, I don't see any other way. > > > in order to keep the client library simple. To > > do this, pa_stream_volume_get/set() could reuse the same protocol as > > the pa_context_* API but set a flag to let the server know the client > > wants relative volumes. > > How is this compatible with the mixer-app-in-browser use case? How can > the mixer app get the absolute volume, if the browser has set the > relative volume flag for a video app? I think the introspection API > should stay unaffected by the relative volume flag. I probably misunderstood. When you mentioned a flag, I assumed you meant the stream flag, but maybe you meant using another flag in the set volume message. That should work. One consideration is that is it easier to do access control based on the message than based on the message parameters - we might want to disallow the introspection API for an application, but still allow the application to set its own volume. If there's only one "set volume" message used to set both maybe -absolute and always-relative volumes, an access control policy has to inspect the message parameters. I would somewhat prefer having separate messages rather than differentiating with a flag, but that's not a strong opinion. Note that there's no "get volume" message anywhere in the protocol. It's not currently needed, since the "get stream info" message covers that. If the pa_stream_get_volume() implementation uses a cached volume, the "get volume" message is not needed in the future either, because the server will be sending volume update notifications all the time, so the client never needs to explicitly request the volume. -- Tanu
