On Tue, Mar 6, 2012 at 2:46 PM, Nils Philippsen <n...@redhat.com> wrote:
> On Mon, 2012-03-05 at 12:02 -0500, Bill Nottingham wrote:
>> Tim Waugh (twa...@redhat.com) said:
>> > For things like cloud printing, where the print server is a hosted
>> > service somewhere out in the Internet, I think the applications should
>> > be talking directly to it (via the print dialog).
>> >
>> > For a plain network printer, where the printer might not be able to
>> > accept the job while it's busy processing others, you might have to
>> > queue the job and retry it later. So if you are doing that as a user
>> > process, how should that work when you log out, and when the machine is
>> > restarted?
>>
>> It waits until you log in again.
>
> I wonder if that works with longer print jobs:
>
> - User: "I'll kick that one off before the weekend, it might take a
> while, so that I won't disturb others."
> - (User's) cupsd: queues the job in user's home, starts printing onto
> the printer.
> - User logs off after 15 pages of 300 are printed.
> - systemd kills off all processes in user session cgroup, including
> cupsd.
> - User: "Aiiieh!", heads off into the weekend as he has to catch a bus,
> forgets about it.
> - User returns after the weekend, logs in again, cupsd picks up the
> still queued print job from user's home, starts printing the remaining
> 285 pages.
This requires:
* A network printer
* ... that has a 300page paper tray, so it is clearly an industrial one
* ... but does not have a separate print queue
* an user that starts a print job and leaves?
I don't know how much that is likely.
In any case, the per-user cupsd could stay running after the user logs
off until the queue is empty - then there should be no discernible
difference between the system queue and per-user queue until the
system reboots (when it reboots, the per-user cupsd probably wouldn't
start and continue processing the job again - although that could be
arranged as well).
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
