All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Meixner <jsmeix@suse.de>
To: printing-architecture@lists.linux-foundation.org
Subject: Re: [Printing-architecture] Automatic printer setup with Printer Applications
Date: Wed, 24 Feb 2021 13:01:22 +0100	[thread overview]
Message-ID: <bcc4538ef1b6e8ef9395dda295f00eac@suse.de> (raw)
In-Reply-To: <66430674-dc47-4a81-406b-aedefc065a37@gmail.com>


Hello,

On 2021-02-24 12:25, Till Kamppeter wrote (excerpts)
> So udev-configure-printer will get turned into a
> permanent daemon and if it detects a printer plug/unplug
> it does more or less what the former udev-configure-printer
> did, but instead of creating a queue on CUPS it creates
> one on a Printer Application.
...
> We must keep in mind that everything should work in Snaps.
...
> udev-configure-printer will need an interface at all Printer
> Applications where it can send a device ID and the Printer Application
> answers back whether it supports this printer (with driver name), and
> that without the Printer Application talking to the physical printers.
> This interface more or less calls the autoadd callback function of the
> Printer Application. This way udev-configure-printer will find out
> whether there is support for the printer and if yes, by which Printer
> Applications and then prioritize. Great would be if a Printer
> Application also could report back support level (generic,
> third-party, manufacturer, ...). It could perhaps also prioritize
> unknown Printer Applications as they are most probably from the
> manufacturer and not from the distro.

if I understand it correctly the basic idea behind is
that for printer setup inside a container
(I use 'container' as generic name for any isolated environment
  that has no direct access to the outer world e.g. also chroot)
udev-configure-printer acts as proxy for outer world access.

This leads me to a - perhaps crazy - idea:
Why not having a general printer access proxy daemon
that is running on the container host for any printer access
that is needed from inside a container i.e. also for normal
printing operations?

I am not at all a container expert but as far as I know
the usual access method between inside a container and the
outer world happens via network so a "USB access proxy"
that runs on the container host should be accessible via
network from within the container.

But this leads to the next - perhaps even more crazy - idea:
Why not having a USB printer wrapper daemon running on the
container host that wraps a USB printer into a network printer
so that from within the container the Printing Application
sees only DNS-SD announced network printers?


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

  reply	other threads:[~2021-02-24 12:01 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 19:27 [Printing-architecture] Automatic printer setup with Printer Applications Till Kamppeter
2021-02-24  7:37 ` Johannes Meixner
2021-02-24  8:03 ` Zdenek Dohnal
2021-02-24 11:25   ` Till Kamppeter
2021-02-24 12:01     ` Johannes Meixner [this message]
2021-02-24 13:51       ` Till Kamppeter
2021-02-25 10:30         ` Johannes Meixner
2021-02-25 13:37           ` Till Kamppeter
2021-02-25 14:00             ` Johannes Meixner
2021-02-25 13:53           ` Michael Sweet
2021-02-24 12:48     ` Solomon Peachy
2021-02-24 14:01       ` Johannes Meixner
2021-02-24 17:23         ` Till Kamppeter
2021-02-26  9:17           ` Johannes Meixner
2021-02-24 14:17       ` Till Kamppeter
2021-02-25 15:28         ` Solomon Peachy
2021-02-25 22:54           ` Till Kamppeter
2021-02-26 14:59             ` Solomon Peachy
2021-02-25  8:28       ` Zdenek Dohnal
2021-02-25 14:54         ` Solomon Peachy
2021-02-26 10:03           ` Johannes Meixner
2021-02-26 12:28             ` Solomon Peachy
2021-02-27 21:07               ` Michael Sweet
2021-02-24 14:17 ` Michael Sweet
2021-02-24 14:46   ` Johannes Meixner
2021-02-24 18:47     ` Till Kamppeter
2021-02-24 17:40   ` Till Kamppeter
2021-02-24 17:48     ` Michael Sweet
2021-02-24 19:21       ` Till Kamppeter
2021-02-24 20:01         ` Michael Sweet
2021-02-24 20:15           ` Till Kamppeter
2021-02-25  8:52   ` Zdenek Dohnal
2021-02-25  9:24     ` Till Kamppeter
2021-02-25  9:54       ` Zdenek Dohnal
2021-02-25 13:43       ` Michael Sweet
2021-02-25 19:39         ` Till Kamppeter
2021-02-25 13:33     ` Michael Sweet
2021-02-25 15:24       ` Till Kamppeter
2021-02-25 15:30         ` Michael Sweet
2021-02-25 21:51           ` Till Kamppeter
2021-03-02 10:58 ` [Printing-architecture] Future of Printer Setup Tools Till Kamppeter
2021-03-02 12:04   ` Johannes Meixner
2021-03-02 22:52     ` Till Kamppeter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bcc4538ef1b6e8ef9395dda295f00eac@suse.de \
    --to=jsmeix@suse.de \
    --cc=printing-architecture@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.