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.
