[sane-devel] What's local_only and what's not?

Kelly Price strredwolf at gmail.com
Wed Nov 13 00:00:15 GMT 2019


Lets take it from a user perspective for a minute.

"Local" we shall keep defined as "directly attached to the computer
SANE is running on."  Further defined, it can be over serial,
parallel, USB, SCSI, Bluetooth, bitbanged pins, doesn't matter as long
as you don't hit the TCP/IP network stack.  (Note, I haven't seen a
scanner that uses Bluetooth, but if there is one, I want to try it
out!)

"Remote" should thus be defined as "Hitting the TCP/IP network stack
to talk to the scanner."  It could be a "local" that's been turned
into "remote" with saned or it could be a proprietary protocol (HP
all-in-ones).  If you have to use TCP/IP over Ethernet, Wifi, PLIP,
SLIP, PPP, avian carriers (talk about your terrible round-trip
latency) to talk to a scanner, it's "remote."

(Insert your own politics here about binary blobs and such)

Back to the code, then.  I'm reminded of Kung Tzu, who said "If
instructions are unclear, it is the fault of the general.  If
instructions are clear, but not followed, it is the fault of the
soldier."  We should update the documentation to make it clear.  Once
it is clear, we can start blaming programmers.

Still, with the current state of the documentation, I would still
contend the following:  If a backend driver treats "Remote" as "Local"
then it's buggy and needs to be fixed.  If it treats "Local" as
"Remote" then it too is buggy.

On Tue, Nov 12, 2019 at 4:06 AM Olaf Meeuwissen
<paddy-hack at member.fsf.org> wrote:
>
> Hi list!
>
> In GitLab issues #130 and #141 we've run into something interesting ;-)
>
>  #130: https://gitlab.com/sane-project/backends/issues/130
>  #141: https://gitlab.com/sane-project/backends/issues/141
>
> Discussing what `sane_get_devices()` should be considered `local_only`,
> we are no longer sure what is and is not local :-o
>
> Anyone care to chime in with opinions and arguments substantiating them?
>
> > FWIW, the SANE Standard, in section 4.3.3 sane_get_devices, has the
> > following to say:
> >
> >  4.3.3 sane_get_devices
> >
> >  This function can be used to query the list of devices that are
> >  available. If the function executes successfully, it stores a pointer
> >  to a `NULL` terminated array of pointers to `SANE_Device` structures
> >  in `*device_list`. The returned list is guaranteed to remain unchanged
> >  and valid until (a) another call to this function is performed or (b)
> >  a call to `sane_exit()` is performed. This function can be called
> >  repeatedly to detect when new devices become available. If argument
> >  `local_only` is true, only local devices are returned (devices
> >  directly attached to the machine that SANE is running on). If it is
> >  false, the device list includes all remote devices that are accessible
> >  to the SANE library.
> >
> >     SANE_Status sane_get_devices (const SANE_Device *** device_list,
> >                                   SANE_Bool local_only);
> >
> >  This function may fail with `SANE_STATUS_NO_MEM` if an insufficient
> >  amount of memory is available.
> >
> >     **Backend Implementation Note**
> >
> >     SANE does not require that this function is called before a
> >     `sane_open()` call is performed. A device name may be specified
> >     explicitly by a user which would make it unnecessary and
> >     undesirable to call this function first.
>
> Hope this will shed some light in our "darkness" ;-),
> --
> Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
>  GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
>  Support Free Software                        https://my.fsf.org/donate
>  Join the Free Software Foundation              https://my.fsf.org/join
>


-- 
Kelly "STrRedWolf" Price
http://redwolf.ws



More information about the sane-devel mailing list