On Thu, 2007-03-01 at 12:33 +0100, Klaus Singvogel wrote:
We need to mention that the current hal backend needs to be extended to satisfy the new requirements, which actual CUPS system expects from backends. But it seems that upstream developers didn't work on this opportunity till today.
What requirements are you referring to?
Hmm. I had a quick look at the current hal/dbus architecture. I didn't see any pollin by any device so far. Instead an administration process called by the hal/dbus system is executed. I'm speeking about the hal-cups-utils/hal_lpadmin tools. Maybe I'm wrong...
Right. HAL callouts are used to add/remove printers when appropriate.
But if not, then we might replace the hal backend by _any_ backend, and no need to use no longer developed tools (hal backend) is needed. Instead we can use our own mechanism here, even YaST, as soon as YaST supports installation of printers without any need of user feedback (full automatism).
You would have to convert the HAL udis to whatever uri scheme the other backends use. We might be able get the device node in the callout and eliminate some of the work for the backends, but this seems kinda clunky. It would be nice to just take advantage of HAL and use the HAL udis as persistent printer uris.
I want to point out, that there should be no goal to remove the usb backend from the system. The reasons are the manuals, and the CUPS book, which only speaks about this. Also the good help at the cups mailing lists should be mentioned, which is no longer usuable for the customers, if we cut the usb backend off the system.
How are ambiguities between the backends resolved? Having both usb and HAL backends cause the same printer to be detected twice. You need mappings between uri schemes to avoid this, right? Chris --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org