[sane-devel] Sandboxing scanner applications

[Bastien Nocera]

On Sun, 2020-09-20 at 00:28 +0300, Alexander Pevzner wrote:
> On 9/19/20 5:39 PM, Bastien Nocera wrote:
> > I don't understand why you'd be telling me to write code to use
> > saned
> > in a way that it wasn't designed for and the net backend when
> > earlier
> > in the thread you told me that the SANE API didn't allow for ADF
> > detection or PDF scanning. So which is it? ;)
> 
> I actually didn't tell you to use saned.

You just told me to use the existing protocol over AF_UNIX ;)

> You probably have two possibilities now:
> 1) Reimplement sane-net/saned pair on a top of D-Bus transport
> 2) Define new scanning API on a top of D-Bus and implement it on a
> top 
> of SANE (because only SANE provides you a collection of drivers)
> 
> The difference between (1) and (2) is that in a case of (1) your D-
> Bus 
> requests will mimic SANE API, while in a case of (2) it will not be
> so.
> 
> Seems, printing portal API uses the second approach.

I don't know what the API will be modeled after. D-Bus APIs are
versioned, and use dictionaries to pass most properties, so
extensibility shouldn't be a problem.

I'm still waiting for advices about the dependencies from people who
can actually land the code in the upstream repos to get anywhere near
writing code.

> 
> > You're the one that posited something completely wrong with regards
> > to
> > memory usage. I can just as well send image data along with the
> > progress information so that we don't need to have a whole half-gig
> > of
> > data in flight at one point :)
> 
> Do you plan to implement data streaming protocol on a top of D-Bus 
> messaging?

I can pass an fd between the server and the client for that, or I can
send individual sealed memfds. I haven't look at what SANE or IPP Scan
use though.