On Thu, 2020-09-17 at 16:55 +0200, Jörn-Ingo Weigert wrote: > Got it.
Any comments about the questions in my original mail? (dependencies, whether to create a new project, or build it in sane-backends/sane- frontends) > Bastien Nocera <[email protected]> schrieb am Do., 17. Sep. 2020, > 16:04: > > 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. > > > > > 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 > > > > > 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. > > > > 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. > > > > > Or do I miss here something? > > > > > >
