On 17/09/2020 16:04, Bastien Nocera wrote:
On Thu, 2020-09-17 at 15:38 +0200, Jörn-Ingo Weigert wrote:
Hi Bastian,nice idea. As SANE is already network capable to provide
connected scanners to the network,
(simply a network device) it make not really sense, to provide
sane(d) via Flatpak in my eyes.
I have no plans on running saned inside the sandbox. It's about running
a server on the outside of the sandbox, talking to the real hardware,
so that applications don't need direct hardware access.
I was not talking about running saned in the sandbox, but letting the
client app talk IPP out of the sandbox to talk to the hardware driver in
another sandbox.
however, having SANE-based applications like XSane/ scan-image as
Flatpak version, maybe a nice idea.
Most of them are blocking on having a scanner portal, which is what
this is about. For example:
https://github.com/flathub/flathub/pull/1111
And paperwork needs access to all the devices, and ship its own sane-
backends, which means it only works with the scanners supported by
sane-backends:
https://github.com/flathub/work.openpaper.Paperwork
This approach seems really awkward, ending up with having some GUI
applications support your scanner and other's not.
But for this you don't need to modify saned. ...
You need to, if you don't want saned listening on the network, being
auto-activatable, and being able to add a portal/proxy in between so
that scanner access is a changeable permission.
So you want to convert saned into a D-Bus server for the sandboxed apps
to access and saned communicates with the actual scanners outside the
sandbox? So the scanned images get pumped through the D-Bus?
We can't easily filter network calls, and most scanner apps don't need
network access, so giving them network access opens the sandbox for no
good reason.
So you are designing completely new, D-Bus-only protocols for printing
and scanning?
Till
