 |
CAPS Universe documentation
1.0.4
All you need to know to be successful
|
|
CAPS Universe documentation
1.0.4
All you need to know to be successful
|
None yet
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.
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.
And it is even more worse, if in this scenario more than one client is registered.
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.
Affected components:
Backward compatible change:
API change:
Changes available with caps-printing-coordinator-1.1.0
In the regular use case when a job is done, it gets removed from the printing providers queue and a notifier is sent out to interested clients about this removal.
If a printing provider de-registers itself (or it crashes), the jobs already in its queue get removed as well, but no notifier is sent out. Waiting clients will wait forever for the job's removal.
Whenever a printing provider should be removed from the internal database, its queue must be drained first.
Affected components:
Backward compatible change:
API change:
Changes available with caps-printing-coordinator-1.1.0
Some directories contain more than one INI file. In some directories the read order isn't important, but in some other it is. In the CAPS Printer Device Parameter Directory for example the read order is important, since their content can overwrite each other. Thus, some kind of predictable read order is required.
Switch to the scandir() API in libcapsinif. This API supports a version order where file names with numbers in it will be sorted according to these numbers. This includes file names like 1-name.ini, 1-name.ini and 10-name.ini, where the 10-name.ini will be the last one in the list.
Users of libcapsinif should not be aware of this change, since there are no changes in the lib's API. Making use of this new feature is up to the user and the selected INI file names.
caps_inif_dir_read() and caps_inif_dir_merge() both makes use of this new internal feature. But in order to overwrite the same key, caps_inif_dir_merge() must be used. The caps_inif_dir_read() still reports an error if the same key from the same section from the same directory should be overwritten.
Described behaviour available with libcapsinif-1.1.0
Related to 1001 The used notifier mechanism needs improvements
If a printing provider is regularly gone, the last message could still be "Gone".
But if the last state the printing provider reports, was an error state, and then de-registers itself, this message should be kept.
And if a printing provider terminates without de-registering itself, this kind of message should set as well instead of a useless "Gone"
Changes available with caps-printing-coordinator-1.1.1
TBD
Simulate a crash to check if the coordinator correctly clean up jobs and printing providers and correctly notify clients.
Changes available with caps-printing-coordinator-1.1.1
An invalid page-ranges print parameter (e.g. a range outside the amount of available pages in the document) terminates the printing provider in libcapsraster if this invalid page-range leads to an empty print job (e.g. no page to print at all).
Deal with this use case and only finish the print job accordingly.
API change in libcapsraster's caps_rstr_job_attach(). It now returns -ESPIPE in this case. This might need adaptions in users of this function (libcapsdriver and printing providers).
Described behaviour available with libcapsraster-1.1.0
