[sane-devel] SANE2 standard completion

Fri Mar 28 17:51:55 UTC 2008

Hi,

On 28.03.2008, at 18:40, Oliver Rauch wrote:

> I can not believe it.
>
> There is someone who says I will start working on SANE2 and you have
> nothing better to do than to tell him it is better not to do it.

I did not tell him not to, but expressed my disbelieve in the whole  
rewrite
"everything" approach.

You did not even reply ta my last mail where I note that TWAIN is not
that far off, and also has the quite same notion regarding frontends and
backends.

> This is called progress. Really good.

I do not call ever changing APIs a progress, a process in which probably
a lot of older drivers will just be left lingering around and vanish.

Microsoft has not archived such a penetration because they changed
the API thus annoyed users and developers all the time, but preserved
some sort of compatibility.

LIkewise X-Windows and Linux do not break (at least the external) API
continuously. And yes, if you do a Google search you notice I contribute
to all of them.

If some of you have too much free time they better grab one of the not
yet supported devices and get some new backend running, or existing
one improved. Changing internal or external APIs for god's sake does
not look too useful from my perspective.

Still, that is MHO - you are free to do whatever, even implement an
API that we do still not agree on.

I can tell you one thing fore sure, before I rewrite my backend for your
fun, I rather go and join the TWAIN working group.

Yours,
   René

> Best regards
> Oliver
>
> Am Freitag, den 28.03.2008, 08:52 +0100 schrieb Rene Rebe:
>> Have you counted thru how many developers are willing to rewrite
>> their code (backends, frontends, etc.) for this arbitrarily defined  
>> SANE
>> 2 "thing" ?
>>
>> My votes still are: preferably compatibly change SANE 1 or adopt
>> TWAIN for Linux.
>>
>> On 27.03.2008, at 18:22, stef wrote:
>>
>>> 	Hello,
>>>
>>> 	before any work can start on SANE 2, the current proposal has to be
>>> completed.
>>>
>>> 	The major change is the image data format. SANE 2 will be able to
>>> handle new formats easily (which matches the current needs,
>>> especially regarding ir
>>> channel). There will be 2 major image format, one pixel oriented and
>>> the other will give images as a mime attachment. There is also
>>> standard part for button handling.
>>>
>>> 	Here is a summary of the differences between SANE 1 and SANE 2
>>> proposal standards:
>>>
>>> structures changes:
>>> 	- the SANE_Device struct has more fields, giving contact
>>> information about the devices in case of bug, and the ability to
>>> send device capability flags
>>> 	- the SANE_Parameters changes to suit the image format improvement.
>>> It also gives new informations such as a proposed filename and X/Y
>>> dpi.
>>> 	
>>> options changes:
>>> 	- capability hidden and allways settable added
>>> 	- more commonly used options are now part of the standard
>>>
>>> SANE operations changes:
>>> 	- sane_open has a SANE_Device ** parameter
>>> 	- scanner's button handling
>>>
>>> newtwork operation:
>>> 	The Network Protocol chapter seems to lag behind the SANE 1
>>> chapter, and the SANE_NET_OPEN call needs to be updated to reflect
>>> sane_open evolution.
>>>
>>> 		The current proposal is in good shape, and the change regarding
>>> image format seems to suit the current need for new formats.
>>> Converting current backends
>>> to SANE2 doesn't seem that difficult.
>>>
>>> 	But before starting, there are some things I'd like to see in the
>>> new standard:
>>> 	- the current code flow is
>>> 	sane_init
>>> 		sane_open
>>> 			sane_start
>>> 				sane_read
>>> 			sane_cancel
>>> 		sane_close
>>> 	sane_exit
>>> 	
>>> 		rather than calling sane_cancel at the end of scan, I'd like to
>>> have a sane_end function. Leaving the use of sane_cancel for
>>> canceling the scan like it allready does. This new function would do
>>> about the same, but code flow would be cleaner and easier to
>>> understand:
>>> 	sane_init
>>> 		sane_open
>>> 			sane_start
>>> 				sane_read
>>> 			sane_end
>>> 		sane_close
>>> 	sane_exit
>>> 	
>>> 	- the proposed button handling would surely be better if we create
>>> sane_lock_buttons(), sane_update_buttons() and sane_unlock()
>>> buttons, instead
>>> of doing this with control options.
>>> 	
>>> 	- we should also add something about panels. Would some control
>>> options be enough,  or do we also need some lock/update/unlock
>>> behavior ?
>>> 	
>>> 	- there are some issues about backends configuration. In order to
>>> be detected, some backends need their  configuration files tweaked.
>>> I think that
>>> having well-known configuration options would improve  the situation
>>> and would
>>> also let us have a common way of accessing configuration parameters
>>> across
>>> backends.
>>> 	
>>> 	- do we want to improve warmup handling ? Currently there is no
>>> feedback when warming-up is going on, which is sometime confusing,
>>> we can have the feeling that nothing is happening. Do we want a
>>> sane_warm_up() or a
>>> SANE_STATUS_WARMING_UP would be enough ?
>>> 	
>>> 	There are other points that I feel they could be improved, but
>>> could be done as we develop SANE2:
>>> 	- we need a sane type for scanner buttons. Either we rename the
>>> SANE_TYPE_BUTTON to SANE_TYPE_SOFT_BUTTON and use SANE_TYPE_BUTTON  
>>> for
>>> physical buttons, or we create a SANE_TYPE_HARD_BUTTON. So that a
>>> frontend can easily detect hardware buttons. There should be a list
>>> of well-known buttons
>>> description to use when  possible.
>>> 	- a SANE_TYPE_PANEL would be handy
>>> 	- since there are well-know options there should be well-known
>>> groups, and the SANE_CAP of these options should also be given.
>>> 	- a SANE_STATUS_LOCKED could be added to handle the case where the
>>> hardware lock of a scanner has been left.
>>> 	
>>> Regards,
>>> 	Stef
>>> 	
>>> 		
>>>
>>> -- 
>>> sane-devel mailing list: sane-devel at lists.alioth.debian.org
>>> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
>>> Unsubscribe: Send mail with subject "unsubscribe your_password"
>>>           to sane-devel-request at lists.alioth.debian.org
>>
>> -- 
>>  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
>>  http://exactcode.de | http://t2-project.org | http://rene.rebe.name
>>
>>
>

-- 
   René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   Geschäftsführer: Susanne Klaus, René Rebe
   Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B
   USt-IdNr.: DE251602478
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name