On 3/2/20 10:24 AM, Klaus Kämpf wrote:
There are some WSD-discovery tools out there.
Both
https://github.com/christgau/wsdd
and
https://github.com/roncapat/WSD-python
work nicely on Linux.
None of them works for me. WSD-python is more lucky, it at least
receives some reply from device, which it can't parse.
May I ask you to try, if my discovery program finds your scanner?
https://github.com/alexpevzner/airscan-discover
I'd like this kind of discovery be added to saned, the sane daemon.
The only thing saned actually does is exporting local scanner into network.
It actually would be much better to reorganize SANE around some daemon,
which will:
1) Perform discovery in background and handle PnP
2) Provide enough privileges for USB access
3) Provide interlocking between SANE-capable applications, that runs
in the same time.
I think, architecture should be the following:
1) Daemon loads all necessary backends, based on dynamic
discovery/configuration (like sane-dll does it now), and does it early,
so when users want to scan, everything already initialized and there is
no annoying delay on startup
2) Daemon exposes scanners using some kind of IPC
3) There is one additional backend needs to be written, intended to
be loaded directly by applications - it's responsibility is to
communicate with daemon as a client, using daemon's IPC
This is will be also quite natural, if networking will also be handled
by this daemon. May be, using IPP-scan rather that SANE native protocol.
Among others, it will allow SANE API to change. Currently, switch to
SANE 2.0 API will break all backends. With a central daemon, it will be
possible to perform a translation between API versions, so daemon could
actually be able to load both SANE 1.0 and SANE 2.0 backends, and two
client backends needs to be implemented, for both API versions (IPC
could be the same)
--
Wishes, Alexander Pevzner ([email protected])
