1001 The used notifier mechanism needs improvements

Note: The following description is printing provider centric, but it is valid for the job notifiers as well.

The original idea was, if a new printing provider registers itself at the printing coordinator, the following notifier (dbus: signal) spread to interested applications will wake them up and let them retrieve the printing provider's base information and state information.

There is no difference if the printing provider registers itself or just reports its state change: the current notifier implementation just sends out the printing provider's ID and it is up to the interested applications to query back the information they want for this ID. Thus, all applications monitoring the printing providers need something like a local cache to store the full information about a specific printing provider.

The expectation is, if they receive a notifier with a yet not locally stored printing provider ID (e.g. unknown), they query for the printing provider's base information once, and the printing provider's state on each further change notifier for this printing provider ID. The idea behind was: keep the required traffic low for these kind of updates.

Issue

‍The current notifier implementation is racy regarding more than one recipient and rapid change reports.

Due to the two steps of the notifier in one way and the following requests as a result of this notifier, there is the risk of losing state changes for an application if the notifiers are arriving rapidly. Depending on processing speed, system load and the use of 'main loops' the available printing provider information at the printing coordinator is already changed when the interested application has received the notifier and queries back for the corresponding information: the notifiers and the information do no longer match.

More than one client registered

Slow notifier processing

And it is even more worse, if in this scenario more than one client is registered.

Solution

One goal was, the data sent over the DBUS should be kept small.

The base information about printing providers is more or less static and can be retrieved by clients once per printing provider. Changing this information can be done by terminating and re-starting a printing provider. All clients can retrieve the new base information once again.

Only the run-time related state information changes frequently. And it makes sense for a client to catch all available state information (think about error states and messages) to present it to its users.

Since it makes less difference in data amount on the DBUS, if data is sent on request after a notifier or sent within the notifier itself, this change will add the run-time state information about printing providers and jobs into the notifier itself.

This ensures, all interested clients will receive the state information regardless of their own load or the system load and any delay. It might be, the state information isn't up-to-date anymore if there is already the next notifier in the input queue. But none of these notifiers and their embedded state information are lost anymore.

It also simplifies the printing coordinator, since it no longer needs to cache already gone printing provider information until some client asks for it.

Impact

Affected components:

libcapsclient (notifier reception)
printing coordinator (notifier transmission)
DBUS interface (notifier content)
client applications (notifier call back functions)

Backward compatible change:

no

API change:

yes (libcapsclient, processing notifiers and call backs)

Note: Due to code simplification, there is now a risk, a new printer or job gets an ID which is already known to some clients.

State

Changes available with caps-printing-coordinator-1.1.0