[sane-devel] SANE V2

[Oliver Rauch]

On Wednesday 04 December 2002 11:08, Enno Fennema wrote:

> 2) SANE_Handle
> A SANE_Handle points to a very important structure, viz.

I do not see an advantage of this and I do not see a reason to do any cha=
nges=20
here. The way sane1 does handle it does work.
The sane standard is defined as a functional approach. It is not an objec=
t
oriented approach, it does not make sense to mix both aprroaches.

>
> 2) SANE_Device
>
> typedef struct SANE_Device {
>     struct SANE_Device *next;
>     SANE_String_Const name;=09/* unique device name */
>     SANE_String_Const vendor;=09/* device vendor string */
>     SANE_String_Const model;=09/* device model name */
>     SANE_String_Const type;=09/* device type (e.g., "flatbed scanner") =
*/
>     SANE_String       devname;=09/* from sane.conf eg. /dev/usbscanner0=
 */
> }=09SANE_Device;
>
>
> <<
> next pointer: If sane_get_devices() returns a list of devices rather
> than an array it is easier for a meta-backend to string all those lists
> together.
>
> When enquiring into models managed by a particular backend
> sane_get_devices need only return the pointer to the first device
> managed by it, assuming that in the backend they are also linked into a
> list.
>
> devname: How to open the device with an operating system dependent way.
> See also comments on config file.
>
> I have no serious problems with all the other fields proposed already
> but am worried that you may be going overboard with detail  like which
> floor the printer is on and e-mail addresses.
>
> Most people use only very few scanners and they know which one is which=
=2E

These information are really important. May be 90% do not need the
field device_location because they use the scanner locally, but when
the scanner is available on the network then this makes sense.

Email of backend author and URL of backen website are also important
(for me, beause I get several backend related mails because xsane can
not display a contact address for the backend in the moment).


> 5) Option descriptor
> Include a one-character shortname for common options to be used by eg.
> get_opt_long().

This is something that does not fit into the sane standard, it has to be
managed by the frontend.

>
> Is there any point in including a SANE_Value (union word, fixed, char*)
> in an option descriptor
> containing the current value? Not quite sure myself/not very important.
>
>
> 6) Configuration files
> Agree a format for a standard /etc/sane.conf file.
I do not think it makes sense to create one large
conf.file that includes all backends.=20
This makes it harder to include external backends
and has no advantage, but it increases the risk
that something breaks.
But it makes sense to use more common options.

Oliver

--=20
http://www.xsane.org
http://www.mostang.com/sane
http://www.rauch-domain.de
mailto:Oliver.Rauch@Rauch-Domain.DE