[sane-devel] SANE 1.1.0 Release discussion

[Till Kamppeter]

This is a much better solution than coming with a completely new SANE2 
API. At the Linux Foundation Summit in April we have decided on taking 
the SANE1 API into LSB 4.0, so that scanner manufacturers can make 
distribution-independent LSB-based scanner driver packages.

Standardizing on the driver structure, like option names and groups, 
debug modes, ... is also a great improvement step without need of API 
changes. Please post specs soon, so that I can add them to the driver 
design guidelines

https://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers

(perhaps the Wiki page needs to be renamed sooner or later, as with the 
LSB DDK I am also addressing scanner drivers).

Also the planned release schedule is great, as this way SANE 1.1.0 will 
make it into the fall editions of the major Linux distributions (Ubuntu 
Intrepid, Fedora 10, ...).

    Till



m. allan noah wrote:
> Lets talk about SANE 1.1.0 release, both timetables and deliverables.
> I have tried to pick some things from recent discussions, and build on
> the momentum provided by stef and julien. It is not my intention to
> hijack this process, but I have some spare cycles coming up, and we
> are all tired of talking :)
> 
> I have five general points for 1.1.x:
> 
>  - no changes to function calls
>  - no changes to structures
>  - 1.0 backends forward compatible with 1.1
>  - improve backend consistency
>  - support more advanced scanners
> 
> Based on those ideas, I propose:
> 
> 1. Consistent, translatable option groups (please add/change to this list):
> 'Standard' = source, mode, resolution
> 'Geometry' = x/y and paper size params
> 'Enhancement' = bright/gamma/contrast/thresh, rif, sharpen, halftone
> settings, etc
> 'Advanced' = compression, calibration, double/manual feed controls,
> backlights, tests, dropout, etc
> 'Sensors/Buttons' = an option for every hardware button or sensor
> 
> others?
> 
> 2. Consistent well known-options, button handling and papersize come
> to mind. others?
> 
> 3. Two new return codes: SANE_STATUS_HW_LOCK to tell the frontend that the
> scanner has a hardware lock installed, and SANE_STATUS_WARMING_UP for lamp.
> 
> 4. More SANE_FRAME types, jpeg, fax, IR, text, xml.
> 
> 5. Add SANE_TYPE_HW_BUTTON for scanners' buttons. The constraint field would
> allow to distinguish between push buttons (0 or 1 )and 'wheel buttons' (0 to
> N).
> 
> 6. Common debugging bitmask:
> 
> 1 major errors
> 2 minor errors
> 4 function start/stop msgs
> 8 function detail msg
> 16 SANE_OPTION processing msgs
> 32 calibration msgs
> 64 outgoing command dump
> 128 incoming data dump
> 
> help me fix that...
> 
> 6. Add common configuration reading function in sanei_* so that new or
> maintained backends can benefit from it. Wholesale config file restructuring?
> 
> Other things from stef's list have been left out because the dont meet
> my 5 points, anyone else have some more?
> 
> My plan is to work on this over the next two months, and aim for a
> feature freeze around July 4th, with release close to July 30th,
> though we could certainly accelerate that with some help.
> 
> Comments welcome.
> 
> allan