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
