alexpevzner / sane-airscan-unstable

Unstable branch of https://github.com/alexpevzner/sane-airscan
Other
3 stars 3 forks source link

Exposing device manufacturer via SANE options. #12

Closed fletcherw closed 4 years ago

fletcherw commented 4 years ago

cc: @yetamrra

For Chrome OS' use of sane-airscan, it would be nice to be able to read the the manufacturer of an open sane-airscan device using option descriptors. Is this something that you would be supportive of?

It is possible to get this information from list_devices(), but that can be a slow process, so we'd like to avoid doing that unnecessarily.

At least for eSCL, we thought this option could just pass through the MakeAndModel field. I'm not sure if WSD has a similar field that could be used. If you think it's okay, I'm happy to do the implementation work.

alexpevzner commented 4 years ago

One little problem: some device description string always available, but will it include manufacturer name or not, depends on device (for eSCL too).

For example, this is Kyocera ECOSYS M2040dn:

<pwg:MakeAndModel>Kyocera ECOSYS M2040dn</pwg:MakeAndModel>
<pwg:SerialNumber>VCF9192281</pwg:SerialNumber>
<pwg:ModelName>ECOSYS M2040dn</pwg:ModelName>

This is Canon MF260:

<pwg:Version>2.63</pwg:Version>
<pwg:MakeAndModel>CNMF260 Series</pwg:MakeAndModel>
<pwg:SerialNumber>2EH18938</pwg:SerialNumber>

And this is HP OfficeJet Pro 8730:

<pwg:Version>2.5</pwg:Version>
<pwg:MakeAndModel>HP OfficeJet Pro 8730</pwg:MakeAndModel>
<pwg:SerialNumber>CN783F60W1</pwg:SerialNumber>

Actually, I extract this information at discovery stage (from ty="xxx" for DNS-SD and from device metadata for WS-Scan), with the same limitations as explained above.

If device is opened using direct URL (see https://github.com/alexpevzner/sane-airscan/issues/25), this information comes together with that URL.

And for WSD, unlike eSCL, this information available only from WS-Discovery, and not available from WS-Scan protocol.

fletcherw commented 4 years ago

You make a good point that the MakeAndModel field may not specify this information explicitly. For our purposes that should be OK though.

I looked a bit but was unable to find a clear reference for the WS-Scan protocol. Do devices that support WS-Scan also support WS-Discovery? If so, then shouldn't you still be able to query the device for that information?

For direct URL, would it be possible to populate that information from the scanner depending on the protocol used rather than from the scanner name provided by the user?

alexpevzner commented 4 years ago

I looked a bit but was unable to find a clear reference for the WS-Scan protocol. Do devices that support WS-Scan also support WS-Discovery? If so, then shouldn't you still be able to query the device for that information?

It makes sense only for direct URL. If discovery is in use, all information gathered by discovery is available.

WSD discovery workflow is following:

  1. Find a device, using UDP multicasting - it returns one or more URLs for metadata exchange
  2. Query a metadata - it returns one or more URLs for particular function (scanning, printing and so on)

URLs obtained in steps 1 and 2 are not the same, and nobody promised that they are interchangeable. So if device opened via direct URL, the answer is "no", because direct URL - is URL for function, not for metadata exchange

For direct URL, would it be possible to populate that information from the scanner depending on the protocol used rather than from the scanner name provided by the user?

How do you plan to obtain direct URL? If from user, it is not a good idea, because URL consist from 1) IP address 2) TCP port 3) path. User knows only IP address. TCP port in not the same between devices, and in the WSD case, path also is not the same, and usually it is not possible to guess this information from the device manual.

If URL comes from your discovery process, when you discover the URL, you already have model name, just pass it down to the backend

fletcherw commented 4 years ago

URLs obtained in steps 1 and 2 are not the same, and nobody promised that they are interchangeable. So if device opened via direct URL, the answer is "no", because direct URL - is URL for function, not for metadata exchange

I understand now, thank you.

If URL comes from your discovery process, when you discover the URL, you already have model name, just pass it down to the backend

It will be coming from the discovery process, so just reporting the value passed in by the user seems like it should work just fine.

alexpevzner commented 4 years ago

Is this issue still relevant? Can I close it?

fletcherw commented 4 years ago

I still need to work on this, but we can close it the issue tracker for now.