On Sat, 2004-07-17 at 07:49 -0400, Jody Goldberg wrote: > On Thu, Jul 15, 2004 at 02:00:20PM -0400, Colin Walters wrote: > > > > As mentioned before, this requires a D-BUS patched CUPS daemon in order > > to function at all. For reference, I've added the patch to the eggcups > > module. I'd like to consider the eggcups module the canonical reference > > for this patch, so if you are a distributor and adopt it, and need to > > modify the patch for any reason, please let me know. > > > > Unfortunately I don't think I'll have time in the near future to support > > the non-DBUS case. > > This is going to be a sticking point. While the d-bus support is > definitely nice, I don't see us being able to depend on it's > existence in GNOME proper. On the corporate level we can all > attempt to ship with the patch, but wearing my community hat I don't > see us requiring it even when it merges into cupsd. IMO we can't > force a user to upgrade some piece of infrastructure to work. > > We could potentially supply a fallback gnomeprintd which consists of > the cupsd d-bus patch and some polling of cupsd. It's a brutal > hack, but would likely provide a decent fallback. Polling cupsd how? The key bit of information that the D-BUS patch exports is the remote job ID. Currently cupsd invokes its IPP backend, which sends the job to the remote print server. It gets the job id on the remote server, then optionally uses it to wait until the job is complete. But the job id never gets back to the user, where we need it to do polling ourself on the job status. The cups daemon doesn't proxy the remote job status for us, and even if it tried, I'm not sure it's the right place to do it anyways. For example, one advantage of the way things work now is that when the user logs out, there is no longer any polling of the user's active jobs. Eventually though I do think we will want to have some sort of per-user print daemon that queues up jobs and speaks IPP directly to remote printers. That will remove the need for a D-BUS patched cupsd, and makes some issues like dealing with printers that require authentication much easier. Then the system cupsd would only handle local printers and picking up the cups printer notification broadcasts. Maybe eggcups could eventually become this daemon. Really this whole system cupsd versus per-user are exactly analogous to the difference between a system MTA versus the user apps speaking SMTP directly. The latter approach is much more flexible, and I think it's clearly the right one.
Attachment:
signature.asc
Description: This is a digitally signed message part