On Fri, 2014-02-14 at 02:49 +0600, Alexander E. Patrakov wrote: > I have also reread the API page, and I think that it would be nice to > specify event ordering and/or introduce a Sync event that is fired after > a group of related changes (the idea comes from the SYN_REPORT event in > the input subsystem). > > Suppose that there is a mixer interface that wants (independently of any > policy module) to display all volume controls, grouping them into two > tabs: "routing nodes" and "everything else" (just for illustration). To > do so, it would listen for RoutingNodeAddedEvent and > VolumeControlAddedEvent (and the corresponding removals). On getting a > VolumeControlAddedEvent, there is no way to decide on which tab to put > this control. One solution would be to always put it onto the > "everything else" tab, and move it if the corresponding > RoutingNodeAddedEvent is emitted. But that is not flicker-free. With the > Sync event, one would be able to avoid updating the GUI until getting it. I like the sync event idea. It's not possible to implement it optimally with the current PulseAudio client API, because PulseAudio doesn't send such sync events, but I think it should be added to the web API anyway. Actually, even without sync events in PulseAudio, it's already possible to know that you have a consistent state in case of new object and object change situations, only object removal is problematic. The problem of inconsistent state occurs when a PulseAudio client receives an event, but actually multiple things happened that are part of the same "logical event", so there are more events queued. The PulseAudio client doesn't know anything about those queued events. Luckily, in case of new object and object change events, this is not a problem, because the client will anyway have to query the object state, because the events don't contain that information. If there are queued events, the client will process them before it gets the answer to its query operation. The client knows that it has consistent state information when there are no query operations in flight. The web browser can issue the Sync event at this point. The exception is the object removal event: that doesn't require the client to do any querying, so the client doesn't know if there are more change events queued after the object removal event. The web browser will have to issue the Sync event blindly after each object removal event. This is probably not a huge problem, but we could fix this anyway by adding a sync event to the PulseAudio API (it should be pretty simple to implement: modify defer_cb() in core-subscribe.c so that it sends a sync event after it has drained the event queue). -- Tanu
