<div class="gmail_quote">On Wed, Mar 9, 2011 at 11:46 AM, m. allan noah <span dir="ltr"><<a href="mailto:kitno455@gmail.com">kitno455@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2011/3/9 Warren Turkal <<a href="mailto:wt@penguintechs.org">wt@penguintechs.org</a>>:<br>
<div class="im">> 2011/3/9 ABC <<a href="mailto:abc@telekom.ru">abc@telekom.ru</a>><br>
<br>
</div><div class="im">> What i think should actually happen is that sanei should have it's own<br>
> method for dealing with usb (and other busses) in whatever form it takes<br>
> (e.g. /dev/scanner dev file or libusb or scsi device or whatever). Sanei<br>
> should call any callbacks into the backend with a generic form for the bus<br>
> type instead of exposing it's innards. Assuming that a string is the best<br>
> form for that generic form, something like "usb:vendor_id:product_id" is<br>
> probably reasonable.<br>
<br>
</div>...<br>
<br>
And that suggestion does not deal with two identical scanners attached<br>
to the machine.</blockquote><div><br></div><div>This is a strawman argument as I think it's pretty clear that the struct would need to include more fields to handle that, and this wasn't a complete example. For example, bus id and device number could be added to the usb struct.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> And the 'struct' version with a single callback<br>
requires us to use enum every possible transport thru a single<br>
function in sanei, which breaks down with a backend specific<br>
transport.<br></blockquote><div><br></div><div>We could allow backend implemented transport by having a transport that defers to the backend implementation. For example, we could add a backend_attach function pointer to the attach_funcs struct that would be take an opaque string as the current implementation does. There's no reason we still couldn't allow that development use case if it was needed.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If a backend supports multiple transports, it can use multiple<br>
callbacks (or callback wrappers) which set the transport in the<br>
scanner struct, in addition to the opaque string. Now, this breaks<br>
down if two different transports use the same name, or if a backend<br>
treats the string as non-opaque. Though the last might be required in<br>
the case of a scanner which cannot be auto detected, like a tcp<br>
machine. I think that's the case here?</blockquote><div><br></div><div>I don't see why tcp can't be treated like the other transports. The tcp_device_info could something like the following:</div><div>struct tcp_device_info {</div>
<div> SANE_String_Const hostname;</div><div> SANE_Integer port;</div><div>}</div><div><br></div><div>Personally, I would prefer to use uint16_t for the port since I think it's more accurate with my intention, but I think that the SANE_Integer type should work.</div>
<div><br></div><div>When the tcp_attach method is called, it would get the tcp_device_info struct and could make a connection (possibly with a library function that's not part of the SANE backend API).</div><div><br>
</div>
<div>It's possible that a better name for the *_device_info structs might be *_transport_info or something like that.</div><div><br></div><div>Thanks,</div><div>wt</div></div>