Discussion:
SANE2 standard completion
(too old to reply)
stef
2008-03-27 17:22:41 UTC
Permalink
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
Rene Rebe
2008-03-28 07:52:51 UTC
Permalink
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.
Post by stef
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
- 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.
- capability hidden and allways settable added
- more commonly used options are now part of the standard
- sane_open has a SANE_Device ** parameter
- scanner's button handling
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
- 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
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
- 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
--
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Alessandro Zummo
2008-03-28 08:16:35 UTC
Permalink
On Fri, 28 Mar 2008 08:52:51 +0100
Post by 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.
I believe that Stef has made very clear its intentions
to go toward SANE 2. TWAIn for linux would be a complete
rewrite of everything, and compatible changes to SANE1 are
already available in SANE Evolution
--
Best regards,

Alessandro Zummo,
Tower Technologies - Torino, Italy

http://www.towertech.it
Rene Rebe
2008-03-28 08:34:22 UTC
Permalink
Hi,
Post by Alessandro Zummo
On Fri, 28 Mar 2008 08:52:51 +0100
Post by 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.
I believe that Stef has made very clear its intentions
to go toward SANE 2. TWAIn for linux would be a complete
rewrite of everything, and compatible changes to SANE1 are
already available in SANE Evolution
As SANE2 is a quite complete rewrite anyway, it makes more
sense to adopt and contribute to an wide industry standard
than to try to force yet another incompatible API into the wild.

Btw. I noticed your SANE Evolution fork.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Alessandro Zummo
2008-03-28 10:52:40 UTC
Permalink
On Fri, 28 Mar 2008 09:34:22 +0100
Post by Rene Rebe
Post by Alessandro Zummo
I believe that Stef has made very clear its intentions
to go toward SANE 2. TWAIn for linux would be a complete
rewrite of everything, and compatible changes to SANE1 are
already available in SANE Evolution
As SANE2 is a quite complete rewrite anyway, it makes more
sense to adopt and contribute to an wide industry standard
than to try to force yet another incompatible API into the wild.
It's true that is a de facto standard, but it is so only
for windows machines, right? So given that there is no prior
art in the unix world and that the sane userbase is (I think)
almost Linux, there's no particular reason to go for it.

SANE2 is a rewrite but it has a sense of coherence with
SANE1 and with the user base.
Post by Rene Rebe
Btw. I noticed your SANE Evolution fork.
good ;)
--
Best regards,

Alessandro Zummo,
Tower Technologies - Torino, Italy

http://www.towertech.it
Rene Rebe
2008-03-28 14:16:36 UTC
Permalink
Hi,
Post by Alessandro Zummo
On Fri, 28 Mar 2008 09:34:22 +0100
Post by Rene Rebe
Post by Alessandro Zummo
I believe that Stef has made very clear its intentions
to go toward SANE 2. TWAIn for linux would be a complete
rewrite of everything, and compatible changes to SANE1 are
already available in SANE Evolution
As SANE2 is a quite complete rewrite anyway, it makes more
sense to adopt and contribute to an wide industry standard
than to try to force yet another incompatible API into the wild.
It's true that is a de facto standard, but it is so only
for windows machines, right? So given that there is no prior
art in the unix world and that the sane userbase is (I think)
almost Linux, there's no particular reason to go for it.
Mac OS < 10 and Mac OS X as well. There is no reason
not to use it on Linux, Unix, ...
Post by Alessandro Zummo
SANE2 is a rewrite but it has a sense of coherence with
SANE1 and with the user base.
When the SANE1 user- and application-base has to adapt
to incompatible rewrites they could also adapt to something
more standard.

Btw. most programs, like Gimp, OpenOffice et. al. come with
TWAIN support for the other OSs anyway.

Yours,
--
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
Stefan Below
2009-04-21 07:08:18 UTC
Permalink
Hello,

how can i enable jpeg compression for the fujitsu scanner (4120C)?
I used it a lot last year, but after reinstalling my system, the feature
is no longer available.

So i compiled the lates sane-backends. Bu when i try to compile
sane-frontends, i get the following error-message:

scanadf.c:995: ERROR: »SANE_STATUS_WARMING_UP« not declared.

(there is only one installed instance of sane-backends in /usr/local/.....)

Hope someone can help me
Stefan
m. allan noah
2009-04-21 12:25:47 UTC
Permalink
Yes- the new frame types and new statuses are no longer enabled by
default in sane-backends CVS, because we are preparing for a non-API
changing release.

You will need to edit include/sane/sane.h, and change the '#if 0' to
'#if 1' around the new status values and around the new frame types,
and add a comma after the value right before the #if. Then rebuild and
reinstall sane-backends. If the compression option shows up in
scanimage --help, then you have succeeded.

I dont know if you really need to compile sane-frontends, but if you
do, make sure it can find the updated sane.h, wherever it has been
installed.

allan
Post by stef
Hello,
how can i enable jpeg compression for the fujitsu scanner (4120C)?
I used it a lot last year, but after reinstalling my system, the feature is
no longer available.
So i compiled the lates sane-backends. Bu when i try to compile
scanadf.c:995: ERROR: »SANE_STATUS_WARMING_UP« not declared.
(there is only one installed instance of sane-backends in /usr/local/.....)
Hope someone can help me
Stefan
--
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"The truth is an offense, but not a sin"
Stefan Below
2009-04-22 06:52:02 UTC
Permalink
Hi,
i think i have to change something in the fujitsu source too.
When i compile the backends, i get this warning:
fujitsu.c:6844: Warning: »read_from_JPEGduplex« defined. but not used

changelog from the fujitsu backend:
v92 2009-04-12, MAN
- disable SANE_FRAME_JPEG support (again)

scanadf and scanimage did not show the new features.

Thanks for your help,
Stefan
Post by m. allan noah
Yes- the new frame types and new statuses are no longer enabled by
default in sane-backends CVS, because we are preparing for a non-API
changing release.
You will need to edit include/sane/sane.h, and change the '#if 0' to
'#if 1' around the new status values and around the new frame types,
and add a comma after the value right before the #if. Then rebuild and
reinstall sane-backends. If the compression option shows up in
scanimage --help, then you have succeeded.
I dont know if you really need to compile sane-frontends, but if you
do, make sure it can find the updated sane.h, wherever it has been
installed.
allan
Post by stef
Hello,
how can i enable jpeg compression for the fujitsu scanner (4120C)?
I used it a lot last year, but after reinstalling my system, the feature is
no longer available.
So i compiled the lates sane-backends. Bu when i try to compile
scanadf.c:995: ERROR: »SANE_STATUS_WARMING_UP« not declared.
(there is only one installed instance of sane-backends in /usr/local/.....)
Hope someone can help me
Stefan
--
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
m. allan noah
2009-04-22 13:01:51 UTC
Permalink
No, I protected the code in the backend with #ifdef, but the status
and frames are enums. I'll switch the new ones to #defines, and commit
it to cvs.

allan
Hi,
i think i have to change  something in the fujitsu source too.
 fujitsu.c:6844: Warning: »read_from_JPEGduplex« defined. but not used
   v92 2009-04-12, MAN
         - disable SANE_FRAME_JPEG support (again)
scanadf and scanimage did not show the new features.
Thanks for your help,
Stefan
Yes- the new frame types and new statuses are no longer enabled by
default in sane-backends CVS, because we are preparing for a non-API
changing release.
You will need to edit include/sane/sane.h, and change the '#if 0' to
'#if 1' around the new status values and around the new frame types,
and add a comma after the value right before the #if. Then rebuild and
reinstall sane-backends. If the compression option shows up in
scanimage --help, then you have succeeded.
I dont know if you really need to compile sane-frontends, but if you
do, make sure it can find the updated sane.h, wherever it has been
installed.
allan
Hello,
how can i enable jpeg compression for the fujitsu scanner (4120C)?
I used it a lot last year, but after reinstalling my system, the feature is
no longer available.
So i compiled the lates sane-backends. Bu when i try to compile
scanadf.c:995: ERROR: »SANE_STATUS_WARMING_UP« not declared.
(there is only one installed instance of sane-backends in /usr/local/.....)
Hope someone can help me
Stefan
--
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"The truth is an offense, but not a sin"
m. allan noah
2009-04-23 00:40:35 UTC
Permalink
I just committed an update to sane.h which makes those new entries
into preprocessor macros. So, just change the #if 0 to #if 1 in both
places, and the compression arg will return.

allan
Post by m. allan noah
No, I protected the code in the backend with #ifdef, but the status
and frames are enums. I'll switch the new ones to #defines, and commit
it to cvs.
allan
Hi,
i think i have to change  something in the fujitsu source too.
 fujitsu.c:6844: Warning: »read_from_JPEGduplex« defined. but not used
   v92 2009-04-12, MAN
         - disable SANE_FRAME_JPEG support (again)
scanadf and scanimage did not show the new features.
Thanks for your help,
Stefan
Yes- the new frame types and new statuses are no longer enabled by
default in sane-backends CVS, because we are preparing for a non-API
changing release.
You will need to edit include/sane/sane.h, and change the '#if 0' to
'#if 1' around the new status values and around the new frame types,
and add a comma after the value right before the #if. Then rebuild and
reinstall sane-backends. If the compression option shows up in
scanimage --help, then you have succeeded.
I dont know if you really need to compile sane-frontends, but if you
do, make sure it can find the updated sane.h, wherever it has been
installed.
allan
Hello,
how can i enable jpeg compression for the fujitsu scanner (4120C)?
I used it a lot last year, but after reinstalling my system, the feature is
no longer available.
So i compiled the lates sane-backends. Bu when i try to compile
scanadf.c:995: ERROR: »SANE_STATUS_WARMING_UP« not declared.
(there is only one installed instance of sane-backends in /usr/local/.....)
Hope someone can help me
Stefan
--
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
"The truth is an offense, but not a sin"
--
"The truth is an offense, but not a sin"
Oliver Rauch
2008-03-28 17:40:22 UTC
Permalink
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.

This is called progress. Really good.


Best regards
Oliver
Post by 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.
Post by stef
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
- 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.
- capability hidden and allways settable added
- more commonly used options are now part of the standard
- sane_open has a SANE_Device ** parameter
- scanner's button handling
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
- 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
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
- 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
--
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Rene Rebe
2008-03-28 17:51:55 UTC
Permalink
Hi,
Post by Oliver Rauch
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.
Post by Oliver Rauch
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é
Post by Oliver Rauch
Best regards
Oliver
Post by 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.
Post by stef
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
- 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.
- capability hidden and allways settable added
- more commonly used options are now part of the standard
- sane_open has a SANE_Device ** parameter
- scanner's button handling
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
- 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
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
- 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
--
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
--
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
m. allan noah
2008-03-28 13:46:27 UTC
Permalink
Post by stef
Hello,
before any work can start on SANE 2, the current proposal has to be completed.
and before we can complete it, we must acknowlege that it has not been
touched in 5 years, and many of its contributors are no longer active,
and many current sane devels (myself included) were not party to any
of the discussions.
Post by stef
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.
but the mime type code creates new problems. it will allow any backend
to produce any kind of output that it wishes, as long as there is a
mime-type for it. frontends will never know what to expect. I would
much rather produce a list of known frame types, and put a note in the
standard that frontend devels should expect new types to be added.
this enables us to specify exactly how common types will be presented.
Post by stef
- 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
general idea sounds good.
Post by stef
- the SANE_Parameters changes to suit the image format improvement. It also gives new informations such as a proposed filename and X/Y dpi.
these should be re-addressed.
Post by stef
- capability hidden and allways settable added
- more commonly used options are now part of the standard
general idea sounds good.
Post by stef
- sane_open has a SANE_Device ** parameter
sounds good.
Post by stef
- scanner's button handling
this is overly complicated, and should be re-examined.

[snip]
Post by stef
- the current code flow is
sane_init
sane_open
sane_start
sane_read
sane_cancel
sane_close
sane_exit
sane_init
sane_open
sane_start
sane_read
sane_end
sane_close
sane_exit
this is a simple, single scan case. can you draw up what you think an
ADF or duplex scan would look like? right now, it does sane_start,
sane_read, sane_start, sane_read, sane_start, sane_read,
Post by stef
- 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.
i have implemented button support in the fujitsu backend without any
locking at all, and it works well, and is compatible with SANE1. Maybe
i am missing something, but i dont see the need for the complication.
Post by stef
- we should also add something about panels. Would some control options be enough, or do we also need some lock/update/unlock behavior ?
Control panels vary so widely between scanners, that i dont know if we
can build a generic facility to support them all. can you give some
examples?
Post by stef
- 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.
I might be inclined to go a step further and build a common config
file format, with better sanei_config support library that all
backends could use.
Post by stef
- 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 ?
i would be inclined to use the status value, and perhaps a note in the
spec that the frontend should retry? this enables a backend to send
warm up during sane_start, or first sane_read, or even sane_open i
guess.
Post by stef
- 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.
I would rather not override the type, because we then lose the ability
to have a multi-bit sensor use the same facility. i think this is a
proper use for SANE_CAP_HARD_SELECT, or some new capability bit.

There should be a list of well-known buttons
Post by stef
description to use when possible.
- a SANE_TYPE_PANEL would be handy
maybe not required if you use a cap instead of a type- these could be
merged with the buttons?
Post by stef
- since there are well-know options there should be well-known groups, and the SANE_CAP of these options should also be given.
ok.
Post by stef
- a SANE_STATUS_LOCKED could be added to handle the case where the hardware lock of a scanner has been left.
agreed. though not all machines can detect the lock.

allan
--
"The truth is an offense, but not a sin"
Rene Rebe
2008-03-28 14:49:17 UTC
Permalink
Hi Allan,
Post by m. allan noah
Post by stef
Hello,
before any work can start on SANE 2, the current proposal has to be completed.
and before we can complete it, we must acknowlege that it has not been
touched in 5 years, and many of its contributors are no longer active,
and many current sane devels (myself included) were not party to any
of the discussions.
Actually I was active the time but never saw a need for an incompatible
change that has zero benefit for the 150++ scanners my Avision backend
supports and just consumes more of my time.

Right now the only thing I miss are marks for infra-red frames, and
maybe
a ability to pass duplex data without buffering the rear side, which
becomes
even more of a problem with the next generation, higher end devices I
got
here on my desk due to the immense amount of data generate at that
speed (I got prototypes of future products here, so I can not name
numbers,
but the current devices already support up to 60 pages per minute, which
are 120 images per minute, so you can imagine ...).

Buffering and reading that data just needlessly consumes CPU cycles and
contribute to data processing gaps between the pages.

Btw. I think the consumer scanner market is falling away anyway, because
the main use to scan photos is no longer needed with the rise of digital
cameras. So API innovation are most required for the mostly remaining
need where the document are in use and we need to process more
data with less overhead.
Post by m. allan noah
Post by stef
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.
but the mime type code creates new problems. it will allow any backend
to produce any kind of output that it wishes, as long as there is a
mime-type for it. frontends will never know what to expect. I would
much rather produce a list of known frame types, and put a note in the
standard that frontend devels should expect new types to be added.
this enables us to specify exactly how common types will be presented.
Ack
.
Post by m. allan noah
Post by stef
- scanner's button handling
this is overly complicated, and should be re-examined.
[snip]
Ack.
Post by m. allan noah
Post by stef
- 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
sane_init
sane_open
sane_start
sane_read
sane_end
sane_close
sane_exit
this is a simple, single scan case. can you draw up what you think an
ADF or duplex scan would look like? right now, it does sane_start,
sane_read, sane_start, sane_read, sane_start, sane_read,
I do not see a problem in this call graph. Sure, we could leave the
cancel (or rename it to _end :-), however existing codebase like
frontends (applications) have deal with the current API and
backends (drivers) anyway. This is what I mean when I declare
unnecessary work. The gain is just a little nicer callgraph on
the paper.
Post by m. allan noah
Post by stef
- 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.
i have implemented button support in the fujitsu backend without any
locking at all, and it works well, and is compatible with SANE1. Maybe
i am missing something, but i dont see the need for the complication.
Ditto for the Avision backend.
Post by m. allan noah
Post by stef
- we should also add something about panels. Would some
control options be enough, or do we also need some lock/update/
unlock behavior ?
Control panels vary so widely between scanners, that i dont know if we
can build a generic facility to support them all. can you give some
examples?
Yes, they differ a lot. From profile selection of current Avision (and
OEM) devices, to simplex duplex buttons, to even whole resolution
and color selection of the HP 7400 even in the Avision family of
devices.

I finally support this (except the 7400 which I did not found spare
time for) by just having a single message option in the Avision
backend and decoding anything the scanner might like to tell
the application, like:

4, simplex, 300dpi, ...

(usually just the profile number on mayority of devices).

I decide to go this road as in practice is found it cumbersome
to train every frontend the multitude of possible option. An
application (our own server thing or other stuff) can pick up
whatever it can parse from the IIRC comma separated tokens.
Post by m. allan noah
Post by stef
- 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 ?
i would be inclined to use the status value, and perhaps a note in the
spec that the frontend should retry? this enables a backend to send
warm up during sane_start, or first sane_read, or even sane_open i
guess.
So Ack.

A warmup status code would indeed be useful and is what I already
have ifdef'ed in the avision backend. But we do not need a complete
SANE rewrite for this.
Post by m. allan noah
Post by stef
- a SANE_STATUS_LOCKED could be added to handle the case
where the hardware lock of a scanner has been left.
agreed. though not all machines can detect the lock.
Yep, and still nothing we need all the other changes for.
We could add the single value, most frontends compare for
!= SANE_STATUS_GOOD anyway, and do some sane_strstatus()
or alike otherwise and name it SANE 1.1, 1.2, 1.3, ...

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Alessandro Zummo
2008-03-28 18:02:09 UTC
Permalink
On Fri, 28 Mar 2008 15:49:17 +0100
Post by Rene Rebe
Right now the only thing I miss are marks for infra-red frames, and
maybe
a ability to pass duplex data without buffering the rear side, which
becomes
even more of a problem with the next generation, higher end devices I
got
I'm interested in this.. you receive the data of two pages at
the same time? It's interleaved in some way?
--
Best regards,

Alessandro Zummo,
Tower Technologies - Torino, Italy

http://www.towertech.it
Rene Rebe
2008-03-28 18:14:48 UTC
Permalink
Post by Alessandro Zummo
On Fri, 28 Mar 2008 15:49:17 +0100
Post by Rene Rebe
Right now the only thing I miss are marks for infra-red frames, and
maybe
a ability to pass duplex data without buffering the rear side, which
becomes
even more of a problem with the next generation, higher end devices I
got
I'm interested in this.. you receive the data of two pages at
the same time? It's interleaved in some way?
I speak about the duplex devices here, which have 2 CCDs (or
similar and scan both sides at the same time (long supported by
the Avision backend, btw. :-)

Avision developed several ways to transfer the duplex data (aside
from the few, trivial) paper flipping devices with just a single CCD),
for some they buffer the page in-memory inside the scanner, for newer
ones there are several interlaced variants.

For the interlaced variants I so far buffer the rear stripes in the
backend
and return the backed data every second frame.

Probably the fujitsu backend does something similar.

Yours,
--
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
m. allan noah
2008-03-28 18:19:38 UTC
Permalink
Post by Rene Rebe
Post by Alessandro Zummo
On Fri, 28 Mar 2008 15:49:17 +0100
Post by Rene Rebe
Right now the only thing I miss are marks for infra-red frames, and
maybe
a ability to pass duplex data without buffering the rear side, which
becomes
even more of a problem with the next generation, higher end devices I
got
I'm interested in this.. you receive the data of two pages at
the same time? It's interleaved in some way?
I speak about the duplex devices here, which have 2 CCDs (or
similar and scan both sides at the same time (long supported by
the Avision backend, btw. :-)
Avision developed several ways to transfer the duplex data (aside
from the few, trivial) paper flipping devices with just a single CCD),
for some they buffer the page in-memory inside the scanner, for newer
ones there are several interlaced variants.
For the interlaced variants I so far buffer the rear stripes in the
backend
and return the backed data every second frame.
Probably the fujitsu backend does something similar.
yes- fujitsu is just the same, grep fujitsu.c for COLOR_INTERLACE_*,
you will see several variants.

my (as yet unreleased) backend for the big kodak machines does not
have this problem, because the machines have tons of ram, and buffer
the images themselves, and there is no way to stop it :)

allan
--
"The truth is an offense, but not a sin"
Rene Rebe
2008-03-28 18:28:05 UTC
Permalink
Post by m. allan noah
Post by Rene Rebe
Post by Alessandro Zummo
On Fri, 28 Mar 2008 15:49:17 +0100
Post by Rene Rebe
Right now the only thing I miss are marks for infra-red frames, and
maybe
a ability to pass duplex data without buffering the rear side, which
becomes
even more of a problem with the next generation, higher end
devices I
got
I'm interested in this.. you receive the data of two pages at
the same time? It's interleaved in some way?
I speak about the duplex devices here, which have 2 CCDs (or
similar and scan both sides at the same time (long supported by
the Avision backend, btw. :-)
Avision developed several ways to transfer the duplex data (aside
from the few, trivial) paper flipping devices with just a single CCD),
for some they buffer the page in-memory inside the scanner, for newer
ones there are several interlaced variants.
For the interlaced variants I so far buffer the rear stripes in the
backend
and return the backed data every second frame.
Probably the fujitsu backend does something similar.
yes- fujitsu is just the same, grep fujitsu.c for COLOR_INTERLACE_*,
you will see several variants.
my (as yet unreleased) backend for the big kodak machines does not
have this problem, because the machines have tons of ram, and buffer
the images themselves, and there is no way to stop it :)
WIth "no way to stop", you mean no way to stop the processing? Because
that is also a point that could get improvements in SANE, the backend
should these days better push the data to the frontend, like begin page,
data, end page. As the bigger machines tend to deliver data so fast they
only honor a cancel with n++ pages in memory or on the network wire ...
(or not at all).

IMHO that are areas where SANE could _evolve_, not some cosmetic
mime-types, or s/sane_cancel/sane_end/

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
m. allan noah
2008-03-28 18:34:53 UTC
Permalink
Post by Rene Rebe
Post by m. allan noah
Post by Rene Rebe
Post by Alessandro Zummo
On Fri, 28 Mar 2008 15:49:17 +0100
Post by Rene Rebe
Right now the only thing I miss are marks for infra-red frames, and
maybe
a ability to pass duplex data without buffering the rear side, which
becomes
even more of a problem with the next generation, higher end devices
I
Post by m. allan noah
Post by Rene Rebe
Post by Alessandro Zummo
Post by Rene Rebe
got
I'm interested in this.. you receive the data of two pages at
the same time? It's interleaved in some way?
I speak about the duplex devices here, which have 2 CCDs (or
similar and scan both sides at the same time (long supported by
the Avision backend, btw. :-)
Avision developed several ways to transfer the duplex data (aside
from the few, trivial) paper flipping devices with just a single CCD),
for some they buffer the page in-memory inside the scanner, for newer
ones there are several interlaced variants.
For the interlaced variants I so far buffer the rear stripes in the
backend
and return the backed data every second frame.
Probably the fujitsu backend does something similar.
yes- fujitsu is just the same, grep fujitsu.c for COLOR_INTERLACE_*,
you will see several variants.
my (as yet unreleased) backend for the big kodak machines does not
have this problem, because the machines have tons of ram, and buffer
the images themselves, and there is no way to stop it :)
WIth "no way to stop", you mean no way to stop the processing?
no- i mean no way to tell scanner that you want it to interlace front and back.
Post by Rene Rebe
Because
that is also a point that could get improvements in SANE, the backend
should these days better push the data to the frontend, like begin page,
data, end page. As the bigger machines tend to deliver data so fast they
only honor a cancel with n++ pages in memory or on the network wire ...
(or not at all).
this is true of the bigger machines, it might be 20 or 30 pages ahead
of the wire when the cancel call comes in, especially if you are not
using a compressed image type.

for your other points, i dont really see how push is any better than
blocking pull...

allan
--
"The truth is an offense, but not a sin"
Rene Rebe
2008-03-28 18:44:37 UTC
Permalink
Post by m. allan noah
Post by Rene Rebe
Post by m. allan noah
Post by Rene Rebe
Post by Alessandro Zummo
On Fri, 28 Mar 2008 15:49:17 +0100
Post by Rene Rebe
Right now the only thing I miss are marks for infra-red frames, and
maybe
a ability to pass duplex data without buffering the rear side, which
becomes
even more of a problem with the next generation, higher end devices
I
Post by m. allan noah
Post by Rene Rebe
Post by Alessandro Zummo
Post by Rene Rebe
got
I'm interested in this.. you receive the data of two pages at
the same time? It's interleaved in some way?
I speak about the duplex devices here, which have 2 CCDs (or
similar and scan both sides at the same time (long supported by
the Avision backend, btw. :-)
Avision developed several ways to transfer the duplex data (aside
from the few, trivial) paper flipping devices with just a single CCD),
for some they buffer the page in-memory inside the scanner, for newer
ones there are several interlaced variants.
For the interlaced variants I so far buffer the rear stripes in the
backend
and return the backed data every second frame.
Probably the fujitsu backend does something similar.
yes- fujitsu is just the same, grep fujitsu.c for COLOR_INTERLACE_*,
you will see several variants.
my (as yet unreleased) backend for the big kodak machines does not
have this problem, because the machines have tons of ram, and buffer
the images themselves, and there is no way to stop it :)
WIth "no way to stop", you mean no way to stop the processing?
no- i mean no way to tell scanner that you want it to interlace front and back.
Post by Rene Rebe
Because
that is also a point that could get improvements in SANE, the backend
should these days better push the data to the frontend, like begin page,
data, end page. As the bigger machines tend to deliver data so fast they
only honor a cancel with n++ pages in memory or on the network wire ...
(or not at all).
this is true of the bigger machines, it might be 20 or 30 pages ahead
of the wire when the cancel call comes in, especially if you are not
using a compressed image type.
for your other points, i dont really see how push is any better than
blocking pull...
I found some machines touchy when the data is not cleared, so
in cancel or close you sometimes end up throwing data away
until the device is in a sane state again, ... An future version
of SANE using a push model would make that easier to
code, and IIRC there where issues with endorser pages
might have a scan index no. printed which where thrown
away later on, etc. pp.

It is not a must, as I said I'm more happy with the current SANE
than an artificially forced SANE2. One can usually convert
and poll etc. as needed, despite printed endorser guarantees,
but IIRC we just ended up with some custom scan script that
would throw all images into the database anyway, as you
usually do not use like scanimage in production :-)

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
m. allan noah
2008-04-06 19:16:44 UTC
Permalink
Post by stef
Post by m. allan noah
Post by stef
But before starting, there are some things I'd like to see in the
- 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
Post by m. allan noah
Post by stef
sane_init
sane_open
sane_start
sane_read
sane_end
sane_close
sane_exit
this is a simple, single scan case. can you draw up what you think an
ADF or duplex scan would look like? right now, it does sane_start,
sane_read, sane_start, sane_read, sane_start, sane_read,
I do not see a problem in this call graph. Sure, we could leave the
cancel (or rename it to _end :-), however existing codebase like
frontends (applications) have deal with the current API and
backends (drivers) anyway. This is what I mean when I declare
unnecessary work. The gain is just a little nicer callgraph on
the paper.
actually, i have some code in my private version of fujitsu backend
now, to try and make sane_cancel work properly. and i can say that
stef is right that separating the 'cancel' from 'dont want more
images' would be very nice for ADF programming. without it, i have to
replicate some measure of the 'EOF' sending code into the cancelling
code, so that it can tell if it needs to actually stop the scanner, or
just not start again.

gentlement (and ladies if there are any), i am in favor of starting a
new sane2 draft, with soversion bump.

allan
--
"The truth is an offense, but not a sin"
stef
2008-04-09 04:36:11 UTC
Permalink
Post by m. allan noah
Post by stef
Post by m. allan noah
Post by stef
But before starting, there are some things I'd like to see in the
- 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
Post by m. allan noah
Post by stef
sane_init
sane_open
sane_start
sane_read
sane_end
sane_close
sane_exit
this is a simple, single scan case. can you draw up what you think an
ADF or duplex scan would look like? right now, it does sane_start,
sane_read, sane_start, sane_read, sane_start, sane_read,
I do not see a problem in this call graph. Sure, we could leave the
cancel (or rename it to _end :-), however existing codebase like
frontends (applications) have deal with the current API and
backends (drivers) anyway. This is what I mean when I declare
unnecessary work. The gain is just a little nicer callgraph on
the paper.
actually, i have some code in my private version of fujitsu backend
now, to try and make sane_cancel work properly. and i can say that
stef is right that separating the 'cancel' from 'dont want more
images' would be very nice for ADF programming. without it, i have to
replicate some measure of the 'EOF' sending code into the cancelling
code, so that it can tell if it needs to actually stop the scanner, or
just not start again.
Another case where having a different function for regular end of scan and
error path is for the lexmark backend. The X11xx/X12xx devices don't have a
sensor to detect home position. Parking position must be find by scanning a
white area with a black dot in it.
Currently, when sane_cancel is called, the backend doesn't know if scan is
finished regularly or aborted, so it parks head slowly, scanning to find the
dot because it don't 'know' where the scanning head is. If there were a
difference between 'abort' and 'scans are finished', in case of normal end,
the backend could just go back by the amount of scanned lines, going back
faster.
Post by m. allan noah
gentlement (and ladies if there are any), i am in favor of starting a
new sane2 draft, with soversion bump.
allan
--
"The truth is an offense, but not a sin"s,
Regards,
Stef
René Rebe
2008-04-09 10:48:22 UTC
Permalink
Hi,
Post by stef
Post by m. allan noah
Post by stef
Post by m. allan noah
Post by stef
But before starting, there are some things I'd like to see in the
- 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
Post by m. allan noah
Post by stef
sane_init
sane_open
sane_start
sane_read
sane_end
sane_close
sane_exit
this is a simple, single scan case. can you draw up what you think an
ADF or duplex scan would look like? right now, it does sane_start,
sane_read, sane_start, sane_read, sane_start, sane_read,
I do not see a problem in this call graph. Sure, we could leave the
cancel (or rename it to _end :-), however existing codebase like
frontends (applications) have deal with the current API and
backends (drivers) anyway. This is what I mean when I declare
unnecessary work. The gain is just a little nicer callgraph on
the paper.
actually, i have some code in my private version of fujitsu backend
now, to try and make sane_cancel work properly. and i can say that
stef is right that separating the 'cancel' from 'dont want more
images' would be very nice for ADF programming. without it, i have to
replicate some measure of the 'EOF' sending code into the cancelling
code, so that it can tell if it needs to actually stop the scanner, or
just not start again.
Another case where having a different function for regular end of scan and
error path is for the lexmark backend. The X11xx/X12xx devices don't have a
sensor to detect home position. Parking position must be find by scanning a
white area with a black dot in it.
Currently, when sane_cancel is called, the backend doesn't know if scan is
finished regularly or aborted, so it parks head slowly, scanning to find the
dot because it don't 'know' where the scanning head is. If there were a
difference between 'abort' and 'scans are finished', in case of normal end,
the backend could just go back by the amount of scanned lines, going back
faster.
As the backend controls the device and reads the image data somehow,
it should have knowledge about the actual head position and should be
able to perform the required actions even with the current interface.

Where exactly should there be the problem?

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
stef
2008-04-09 19:27:23 UTC
Permalink
Post by René Rebe
As the backend controls the device and reads the image data somehow,
it should have knowledge about the actual head position and should be
able to perform the required actions even with the current interface.
Where exactly should there be the problem?
Yours,
You are right that a backend can count how many times sane_cancel has been
called after last sane_start() and that also by knowing if all data planned
to be scan has been effectively read, it could sort things. But this a
workaround more prone to bugs than to have a function for regular end of
scan, and another for error code path. It would also have to be coded again
and again into backends needing it.
It is cheap to add, is about a one liner for frontends and help us to write
better backends. For most backends, adding such a function would simply
resolve in renaming sane_cancel to internal_cancel, and have it called by
sane_cancel and the new function. Actively maintained backends will be able
to take advantage of it.

Regards,
Stef
Rene Rebe
2008-04-09 19:38:26 UTC
Permalink
Hi,
Post by stef
Post by René Rebe
As the backend controls the device and reads the image data somehow,
it should have knowledge about the actual head position and should be
able to perform the required actions even with the current interface.
Where exactly should there be the problem?
Yours,
You are right that a backend can count how many times sane_cancel has been
called after last sane_start() and that also by knowing if all data planned
to be scan has been effectively read, it could sort things. But this a
workaround more prone to bugs than to have a function for regular end of
scan, and another for error code path. It would also have to be coded again
and again into backends needing it.
It is cheap to add, is about a one liner for frontends and help us to write
better backends. For most backends, adding such a function would simply
resolve in renaming sane_cancel to internal_cancel, and have it called by
sane_cancel and the new function. Actively maintained backends will be able
to take advantage of it.
You are still just arguing around the dancing cow here.

With a potentially new sane_end whatever function you still would have
to
keep track where the head is. A frontend may still read less data and in
any case you would need to know where the head is to move it that
specific way backwards in such a "CPU-less" "doing every step by
the host" device.

I can still do not see where another function call to signal a scan_end
would help you.
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
stef
2008-04-10 19:33:31 UTC
Permalink
Post by Rene Rebe
You are still just arguing around the dancing cow here.
With a potentially new sane_end whatever function you still would have
to
keep track where the head is. A frontend may still read less data and in
any case you would need to know where the head is to move it that
specific way backwards in such a "CPU-less" "doing every step by
the host" device.
I can still do not see where another function call to signal a scan_end
would help you.
A frontend that reads less data than it required would call sane_cancel().
While I imagine some cases where it may need to do such, frontends will
usually get what they asked for, and call sane_end().
It should also be noted that a frontend that don't call it would still work.

Regards,
Stef
Rene Rebe
2008-04-10 19:49:16 UTC
Permalink
Post by stef
Post by Rene Rebe
You are still just arguing around the dancing cow here.
With a potentially new sane_end whatever function you still would have
to
keep track where the head is. A frontend may still read less data and in
any case you would need to know where the head is to move it that
specific way backwards in such a "CPU-less" "doing every step by
the host" device.
I can still do not see where another function call to signal a scan_end
would help you.
A frontend that reads less data than it required would call
sane_cancel().
While I imagine some cases where it may need to do such, frontends will
usually get what they asked for, and call sane_end().
It should also be noted that a frontend that don't call it would still work.
And when a frontend for a valid or buggy reason reads less than the
backend thinks it shoudl read and calls _end the head will be crashed
into the scanner case???
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Julien BLACHE
2008-03-28 17:40:24 UTC
Permalink
"m. allan noah" <***@gmail.com> wrote:

Hi,
Post by m. allan noah
Post by stef
- scanner's button handling
this is overly complicated, and should be re-examined.
For that and other reasons, I think it'd really be better to have the
frontends be entirely isolated from the backends, as I explained
already.

This would provide a central point (saned) handling the hardware
entirely, it can chat with other things (HAL, anything over D-Bus, you
name it) and we totally avoid the current side effects we have today.

The more I think about it, the more I think this is the way to go.

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Rene Rebe
2008-03-28 17:53:49 UTC
Permalink
Hi,
Post by Julien BLACHE
Hi,
Post by m. allan noah
Post by stef
- scanner's button handling
this is overly complicated, and should be re-examined.
For that and other reasons, I think it'd really be better to have the
frontends be entirely isolated from the backends, as I explained
already.
This would provide a central point (saned) handling the hardware
entirely, it can chat with other things (HAL, anything over D-Bus, you
name it) and we totally avoid the current side effects we have today.
The more I think about it, the more I think this is the way to go.
Sounds a bit Data Source Manager like-ish (in TWAIN terms), definetly
and idea for desktops.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Julien BLACHE
2008-03-28 18:13:09 UTC
Permalink
Rene Rebe <***@exactcode.de> wrote:

Hi,
Post by Rene Rebe
Sounds a bit Data Source Manager like-ish (in TWAIN terms), definetly
and idea for desktops.
Yes.
Rene Rebe
2008-03-28 18:21:00 UTC
Permalink
Hi,
Hi,
Post by Rene Rebe
Sounds a bit Data Source Manager like-ish (in TWAIN terms), definetly
and idea for desktops.
Yes. From what you told about TWAIN the other day, I think I like the
architecture. I don't know enough about TWAIN to tell for sure,
though.
Oh, I forgot to add: we get real locking/device management that way,
too.
The TWAIN standard is open, and here is the link:

http://twain.org/docs/TWAIN19.pdf

Actually the capabilities are even quite similar.

In retrospect I wonder why TWAIN was not used when SANE was
started for the open / free OSs. Maybe just to do it differently than
on Windows and the Mac.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Julien BLACHE
2008-03-28 18:58:17 UTC
Permalink
Post by Rene Rebe
http://twain.org/docs/TWAIN19.pdf
Back in the days, ISTR it wasn't open. I'll try to find some time to
go through it.
Post by Rene Rebe
Actually the capabilities are even quite similar.
That's what makes the most sense I think, so it's no surprise.
Post by Rene Rebe
In retrospect I wonder why TWAIN was not used when SANE was
started for the open / free OSs. Maybe just to do it differently than
on Windows and the Mac.
NIH syndrom? :) I wasn't here back then, but my feeling about TWAIN at
that time (was fiddling with a handheld scanner on Windows 3.11) was
that it was something really complicated, so I can understand why SANE
came out as something simpler.

These days, we may not see TWAIN as something as complicated as we
used to think back then because we're now used to similar designs all
over the place (and the cost of such designs in terms of code and
runtime performance is quite smaller these days, too).

Well, OK, enough random thoughts ;)

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Johannes Meixner
2008-04-01 13:37:35 UTC
Permalink
Hello,
... provide a central point (saned) handling the hardware
entirely,
...
Something much more simple than CUPS, but yeah, basically.
...
Oh, I forgot to add: we get real locking/device management
that way, too.
It may get complicated for all-in-one devices when both
the CUPS backend and the saned try to communicate at the
same time with the device.

The CUPS backend runs only as long as one particular print job
is sent to the device, then it finishes.

To make printing possible, the saned should release
a locked device file when it is not actually in use.

But how to deal with a user who runs a frontend to scan
multiple sheets on a all-in-one device and in between
a (longer) print job comes (e.g. from a remote machine)?

Should the frontend tell the saned to keep the lock until
the last sheet is scanned (i.e. provide something like a
[Lock]/[Unlock] button in the frontend) or might the
print job hinder the user to continue scanning?


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
Julien BLACHE
2008-04-01 16:30:33 UTC
Permalink
Johannes Meixner <***@suse.de> wrote:

Hi,
Post by Johannes Meixner
The CUPS backend runs only as long as one particular print job
is sent to the device, then it finishes.
Same for saned.
Post by Johannes Meixner
But how to deal with a user who runs a frontend to scan
multiple sheets on a all-in-one device and in between
a (longer) print job comes (e.g. from a remote machine)?
Exactly the same situation we have today.

The locking I am talking about is only between SANE clients, in the
sense that it would be possible to tell a user "Sorry, this scanner is
already in use" instead of whatever non-obvious message you get today.

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Étienne Bersac
2008-03-28 17:55:20 UTC
Permalink
Hi,
Post by Julien BLACHE
This would provide a central point (saned) handling the hardware
entirely, it can chat with other things (HAL, anything over D-Bus, you
name it) and we totally avoid the current side effects we have today.
Do you mean having some cups for scanner ?

Actually, i wish not, because users don't want another service. HAL can
launch addon per device which allow to launch nothing if no scanner
present.

On the other end, scanner are more and more for professionnal which
heavily use networked scanner, thus, having a protocol (like ipp for
printing might be a good idea). But who will develop this ? How much
years ?

Regards,
Étienne.
Julien BLACHE
2008-03-28 18:09:23 UTC
Permalink
Étienne Bersac <***@gmail.com> wrote:

Hi,
Post by Étienne Bersac
Do you mean having some cups for scanner ?
Something much more simple than CUPS, but yeah, basically.
Post by Étienne Bersac
Actually, i wish not, because users don't want another service. HAL can
launch addon per device which allow to launch nothing if no scanner
present.
Could you PLEASE stop thinking "HAL" all the time? I don't use HAL, I
don't want to use HAL, I don't need HAL for fsck's sake.

Other OSes do not have HAL.

HAL is, will be and must be an add-on, and nothing more. It must not
be either a dependency or a pre-requisite.
Post by Étienne Bersac
On the other end, scanner are more and more for professionnal which
heavily use networked scanner, thus, having a protocol (like ipp for
printing might be a good idea). But who will develop this ? How much
years ?
Based on the current saned, it can already be achieved:
- link saned statically to libsane-dll (what we know as libsane
today)
- ship libsane-net as libsane
- add a local connection to saned, typically a UNIX socket and listen
to that and that only unless general networking is explicitly
enabled. Ditto libsane only connects to the UNIX socket by
default. (the UNIX socket wins hands down against localhost/TCP)

There, done. Keep all the underlying architecture as far as saned is
concerned.

After that, implement whatever new feature you want in the
backends. The backends API is now a private API between saned and the
backends. Updates to the public SANE API as implemented by libsane
only requires changing libsane. As an added bonus, a compat layer can
probably be offered for current backends that cannot be modified.

The network protocol will also probably need to change at some point,
I haven't thought about that particular point yet. More interactivity,
more status messages and the ability to feed scan data over a unique
TCP stream would be nice.

User ACLs can be added to the mix.

We're losing the ability to link an application to a backend directly
as is possible today, but it's seldomly use and we're getting rid of
those frigging side effects we have today.

If we're redoing SANE, let's at least do it the right way. Investing
time and effort into something that'll only be marginally better than
what we have today makes no sense.

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Rene Rebe
2008-03-28 18:17:04 UTC
Permalink
Hi,
Post by Julien BLACHE
Hi,
Post by Étienne Bersac
Do you mean having some cups for scanner ?
Something much more simple than CUPS, but yeah, basically.
Post by Étienne Bersac
Actually, i wish not, because users don't want another service. HAL can
launch addon per device which allow to launch nothing if no scanner
present.
Could you PLEASE stop thinking "HAL" all the time? I don't use HAL, I
don't want to use HAL, I don't need HAL for fsck's sake.
Other OSes do not have HAL.
HAL is, will be and must be an add-on, and nothing more. It must not
be either a dependency or a pre-requisite.
Post by Étienne Bersac
On the other end, scanner are more and more for professionnal which
heavily use networked scanner, thus, having a protocol (like ipp for
printing might be a good idea). But who will develop this ? How much
years ?
- link saned statically to libsane-dll (what we know as libsane
today)
- ship libsane-net as libsane
- add a local connection to saned, typically a UNIX socket and listen
to that and that only unless general networking is explicitly
enabled. Ditto libsane only connects to the UNIX socket by
default. (the UNIX socket wins hands down against localhost/TCP)
There, done. Keep all the underlying architecture as far as saned is
concerned.
After that, implement whatever new feature you want in the
backends. The backends API is now a private API between saned and the
backends. Updates to the public SANE API as implemented by libsane
only requires changing libsane. As an added bonus, a compat layer can
probably be offered for current backends that cannot be modified.
The network protocol will also probably need to change at some point,
I haven't thought about that particular point yet. More interactivity,
more status messages and the ability to feed scan data over a unique
TCP stream would be nice.
User ACLs can be added to the mix.
We're losing the ability to link an application to a backend directly
as is possible today, but it's seldomly use and we're getting rid of
those frigging side effects we have today.
If we're redoing SANE, let's at least do it the right way. Investing
time and effort into something that'll only be marginally better than
what we have today makes no sense.
+1 from me.

Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Étienne Bersac
2008-03-28 18:39:50 UTC
Permalink
Hi,
Post by Julien BLACHE
Could you PLEASE stop thinking "HAL" all the time?
Could you please stop taking HAL as an offense all the time ?

By talking about HAL, i mean do not impose another system service and
let external project do it on top of SANE, be it either a DBus daemon, a
HAL addon, a regular daemon, etc.

Étienne.
--
Alléluia !
Julien BLACHE
2008-03-28 19:05:37 UTC
Permalink
Post by Étienne Bersac
By talking about HAL, i mean do not impose another system service and
let external project do it on top of SANE, be it either a DBus daemon, a
HAL addon, a regular daemon, etc.
Bar telling "no new service please, HAL can launch things as needed".

Yeah, that's it.

I also quite like the "users don't want another daemon running",
coming from the HAL/udev/FAM/gconfd side. I'm forgetting a couple, I'm
sure.

I'm quite sick of the desktop people trying to overtake
everything. Everything is not a desktop, the desktop is only one use
case. And we DO care about it, thanks very much.

Integrating WITH a desktop doesn't mean writing the whole stack FOR
the desktop. There are things that must be taken into consideration in
the process, but that's it.

Now, please try to understand that.

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
m. allan noah
2008-03-28 19:26:29 UTC
Permalink
Post by Julien BLACHE
Post by Étienne Bersac
By talking about HAL, i mean do not impose another system service and
let external project do it on top of SANE, be it either a DBus daemon, a
HAL addon, a regular daemon, etc.
Bar telling "no new service please, HAL can launch things as needed".
Yeah, that's it.
I also quite like the "users don't want another daemon running",
coming from the HAL/udev/FAM/gconfd side. I'm forgetting a couple, I'm
sure.
I'm quite sick of the desktop people trying to overtake
everything. Everything is not a desktop, the desktop is only one use
case. And we DO care about it, thanks very much.
Integrating WITH a desktop doesn't mean writing the whole stack FOR
the desktop. There are things that must be taken into consideration in
the process, but that's it.
Now, please try to understand that.
yes- especially if you are going to go blogging about us behind our backs :)

allan
--
"The truth is an offense, but not a sin"
Étienne Bersac
2008-03-31 13:29:55 UTC
Permalink
Hi,
Post by m. allan noah
especially if you are going to go blogging about us behind our backs :)
Do you mean i have to post each blog post about SANE here ;)

Étienne.
Étienne Bersac
2008-03-31 13:42:27 UTC
Permalink
Hi,
Post by Julien BLACHE
I also quite like the "users don't want another daemon running"
Personnaly, i don't care to have a cups for scanner. But people in
distributions, dev in other pieces of the stacks and end-users tell so.
Again, we should not impose a service but rather keep at least library
(and the daemon along) in order to allow to bypass the service.
Post by Julien BLACHE
I'm quite sick of the desktop people trying to overtake
everything.
I guess you are labeling me as one of those "desktop people". Desktop
users and developers, distributors and backend developers are sick of
conservative people always considering other people as invader.
Post by Julien BLACHE
Everything is not a desktop, the desktop is only one use
case.
Don't reduce desktop as window manager + xsane.
Post by Julien BLACHE
And we DO care about it, thanks very much.
Sorry, what does mean DO ?
Post by Julien BLACHE
Integrating WITH a desktop doesn't mean writing the whole stack FOR
the desktop.
Where did you read such statment ???
Post by Julien BLACHE
Now, please try to understand that.
Please try to understand end-users.


Étienne.
--
E Ultreïa !
m. allan noah
2008-03-31 14:46:48 UTC
Permalink
Post by Étienne Bersac
Hi,
Post by Julien BLACHE
I also quite like the "users don't want another daemon running"
Personnaly, i don't care to have a cups for scanner. But people in
distributions, dev in other pieces of the stacks and end-users tell so.
Again, we should not impose a service but rather keep at least library
(and the daemon along) in order to allow to bypass the service.
Post by Julien BLACHE
I'm quite sick of the desktop people trying to overtake
everything.
I guess you are labeling me as one of those "desktop people". Desktop
users and developers, distributors and backend developers are sick of
conservative people always considering other people as invader.
ok. this entire line of discussion is not helpful. lets work to build
a consensus, instead of finger pointing.

GUI clients are probably the largest group of _users_ of SANE. CLI
clients probably aquire more _images_. The needs of both groups must
be met.

allan
--
"The truth is an offense, but not a sin"
Étienne Bersac
2008-03-31 14:50:17 UTC
Permalink
Hi,
Post by m. allan noah
GUI clients are probably the largest group of _users_ of SANE. CLI
clients probably aquire more _images_. The needs of both groups must
be met.
Completely agree.

Best regards,
Étienne.
Julien BLACHE
2008-03-31 17:13:20 UTC
Permalink
Étienne Bersac <***@gmail.com> wrote:

Hi,
Post by Étienne Bersac
Post by Julien BLACHE
I also quite like the "users don't want another daemon running"
Personnaly, i don't care to have a cups for scanner. But people in
distributions, dev in other pieces of the stacks and end-users tell so.
You're getting more and more funny as time passes. Let's have a look:
- people in distributions: that would be me and friends of
mine. Having a daemon running for scanner access doesn't bother
me. Having a gazillion daemons running for the GNOME desktop
doesn't bother the GNOME maintainers I know. Case closed.
- end users: they don't know what a daemon is, to begin with. They
hardly care, as long as it all works; if they do care, they're not
end users any more. Case closed.
- dev in other pieces of the stacks: that would be you, I guess?
Hardly relevant, given what I consider to be your lack of expertise
and experience with SANE. Case closed.
Post by Étienne Bersac
Again, we should not impose a service but rather keep at least library
(and the daemon along) in order to allow to bypass the service.
Maintaining SANE as a library has all the problems we know: API/ABI
stability is an absolute must, side effects are an issue, bugs take
all the stack down with them, in messy ways sometimes.

Moreover you totally misunderstood what I proposed if you think
libsane itself is going away as a result. libsane is not going away,
under any circumstances.
Post by Étienne Bersac
I guess you are labeling me as one of those "desktop people". Desktop
users and developers, distributors and backend developers are sick of
conservative people always considering other people as invader.
Yeeeeesh.

Wanna talk about your "INTEGRATE HAL IN SANE NOW OR ELSE..." approach?
Post by Étienne Bersac
Post by Julien BLACHE
Everything is not a desktop, the desktop is only one use
case.
Don't reduce desktop as window manager + xsane.
Don't put words in my mouth, eh?
Post by Étienne Bersac
Post by Julien BLACHE
And we DO care about it, thanks very much.
Sorry, what does mean DO ?
So far it means GUI frontends, hotplug/udev integration, resource
manager (horrible SuSE thing, but hey, it helped), there's been
discussion about mDNS integration and now HAL.
Post by Étienne Bersac
Post by Julien BLACHE
Integrating WITH a desktop doesn't mean writing the whole stack FOR
the desktop.
Where did you read such statment ???
"don't do that because HAL can already do this and that" ?
Post by Étienne Bersac
Post by Julien BLACHE
Now, please try to understand that.
Please try to understand end-users.
I do understand them, far better than so-called desktop developers,
even.


As far as HAL goes, your input is appreciated as long as it is
relevant to the discussion.

I honestly don't understand why you're trying to drive the SANE
development your way. We are discussing options, and all those options
*will* include various improvements at various levels.

If you read my proposal, it talks about a D-Bus interface and HAL
integration explicitely. I did not mention mDNS, but that's trivial to
add.

Now tell me, how do you transparently share scanners from one box to
another without a daemon?

I've been for a couple of years now, I've done quite some work on
packaging SANE and helped as much as I could. In the meantime I've had
countless mail exchanges with users, most of them true end users. I've
worked with clients who have a real need for a better shared
scanner/networked environment.

Now I'm putting this all together, and the best solution I can imagine
is what I proposed. I really think the current architecture doesn't
fit the current needs. SANE2 doesn't quite cut it either.

I think it makes sense. A couple of other people do so too. All of
them do know SANE pretty well. Some of them at least earn or earned
part or all of their living working on SANE for customers.

So, honestly, tell me: who's best informed? Can't you trust us? If you
don't trust me, I assure you that you can trust Rene or Allan. They're
real, experienced backends developers, and they've gone through quite
some things with SANE.

Before you ask, this is not at all a case of "who wins". I think what
I propose makes sense. Others have other ideas and experiences, and in
the end we'll do the right thing, because we know what we're doing.

If you don't trust us and can't resist the urge to sidetrack the
discussion as you do, then, by all means, this is all free software:
roll your own.


Can we please get back to work?

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Étienne Bersac
2008-04-01 06:39:29 UTC
Permalink
Hi,
Post by Julien BLACHE
Now tell me, how do you transparently share scanners from one box to
another without a daemon?
I never said that. I said « how to avoid running service if there is no
scanner plugged ? ». I even implemented a daemon for polling sensor.
Please reread past mail rather than putting words in my mouth.

Étienne.
Johannes Meixner
2008-04-01 13:03:08 UTC
Permalink
Hello,
... I think it'd really be better to have the
frontends be entirely isolated from the backends, as I explained
already.
This would provide a central point (saned) handling the hardware
entirely
To avoid confusion with the cupsd, I like to mention that
the cupsd does not talk to the hardware (i.e. the printer).

In CUPS there are so called "backends" which talk to the
final destination of a print job (usually the printer but
often also a network service like IPP, LDP, or SMB), see
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell


Furthermore I like to mention that the HP printer and scanner
driver HPLIP had in the past such a kind of daemon "hpiod"
which did the actual hardware I/O.

There have been several drawbacks with such a daemon so that
HPLIP dropped the daemon and uses now a library "libhpmud"
which does the actual hardware I/O.

I.e. perhaps in the end a library is better than a daemon?

Perhaps the crucial question is not whether the hardware I/O
is done via a library or via a daemon but to get the frontends
be entirely isolated from the backends regardless if this is
implemented via a daemon or via an additional I/O-library?

I think when a driver for all-in-one devices moved from
a daemon to a library, it might indicate that this is also
true for plain scanner drivers?


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
Emmanuel Fust
2008-03-30 20:25:56 UTC
Permalink
OOooppss, I was a bit late and it is described in a better English than mine.

+10

EF.
Message du 28/03/08 19:09
De : "Julien BLACHE"
- link saned statically to libsane-dll (what we know as libsane
today)
- ship libsane-net as libsane
- add a local connection to saned, typically a UNIX socket and listen
to that and that only unless general networking is explicitly
enabled. Ditto libsane only connects to the UNIX socket by
default. (the UNIX socket wins hands down against localhost/TCP)
There, done. Keep all the underlying architecture as far as saned is
concerned.
After that, implement whatever new feature you want in the
backends. The backends API is now a private API between saned and the
backends. Updates to the public SANE API as implemented by libsane
only requires changing libsane. As an added bonus, a compat layer can
probably be offered for current backends that cannot be modified.
The network protocol will also probably need to change at some point,
I haven't thought about that particular point yet. More interactivity,
more status messages and the ability to feed scan data over a unique
TCP stream would be nice.
User ACLs can be added to the mix.
We're losing the ability to link an application to a backend directly
as is possible today, but it's seldomly use and we're getting rid of
those frigging side effects we have today.
If we're redoing SANE, let's at least do it the right way. Investing
time and effort into something that'll only be marginally better than
what we have today makes no sense.
JB.
Créez votre adresse électronique pré***@laposte.net
1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
Emmanuel Fust
2008-03-30 20:18:21 UTC
Permalink
Message du 28/03/08 22:50
De : "Julien BLACHE"
Hi,
Post by m. allan noah
Post by stef
- scanner's button handling
this is overly complicated, and should be re-examined.
For that and other reasons, I think it'd really be better to have the
frontends be entirely isolated from the backends, as I explained
already.
This would provide a central point (saned) handling the hardware
entirely, it can chat with other things (HAL, anything over D-Bus, you
name it) and we totally avoid the current side effects we have today.
The more I think about it, the more I think this is the way to go.
JB.
Yes !!!!! I had the same feeling many years ago, twain like things with front end and backend coupling by libs/dlopen is a dead end.
With saned, you could cleanly solve the  resource sharing problem, warm-up time pblm, tandby etc.... Your could have a clean network transport but nothing prevent you to have a locally optimized transport for data like shared memory buffers.
And more interestingly, this net-oriented protocol could be designed with extensibility and backward compatibility in mind and saned could easily use directly all old V1 backends or native and rationalized new backend code. V1 like api become and internal API which could evolve as needed.
A new client (frontend) library could be developed and if someone really need it, it could expose a compatible v1 API/ABI (but it not worth it I think).

EF.

Créez votre adresse électronique pré***@laposte.net
1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
m. allan noah
2008-03-30 21:37:14 UTC
Permalink
Post by Emmanuel Fust
Message du 28/03/08 22:50
De : "Julien BLACHE"
Hi,
Post by m. allan noah
Post by stef
- scanner's button handling
this is overly complicated, and should be re-examined.
For that and other reasons, I think it'd really be better to have the
frontends be entirely isolated from the backends, as I explained
already.
This would provide a central point (saned) handling the hardware
entirely, it can chat with other things (HAL, anything over D-Bus, you
name it) and we totally avoid the current side effects we have today.
The more I think about it, the more I think this is the way to go.
JB.
Yes !!!!! I had the same feeling many years ago, twain like things with
front end and backend coupling by libs/dlopen is a dead end.
With saned, you could cleanly solve the resource sharing problem, warm-up
time pblm, tandby etc.... Your could have a clean network transport but
nothing prevent you to have a locally optimized transport for data like
shared memory buffers.
And more interestingly, this net-oriented protocol could be designed with
extensibility and backward compatibility in mind and saned could easily use
directly all old V1 backends or native and rationalized new backend code. V1
like api become and internal API which could evolve as needed.
A new client (frontend) library could be developed and if someone really
need it, it could expose a compatible v1 API/ABI (but it not worth it I
think).
i have long considered such an idea, but it does not change the fact
that we have to design a new external API that provides access to
information that cannot be gotten thru the SANE1 API. Given the amount
of time i think that will take, this new saned wont meet the immediate
need.

As such, i would like to extend SANE1 just a little bit, and i dont
care if we call it SANE2 and give it a new soversion. Then, we can
spend all the time you guys want developing an extensible network
protocol, and turning saned into a real full-time daemon, because we
will have something that is easy for existing backends to use in the
meantime.

allan
--
"The truth is an offense, but not a sin"
Julien BLACHE
2008-03-31 17:17:50 UTC
Permalink
"m. allan noah" <***@gmail.com> wrote:

Hi,
Post by m. allan noah
As such, i would like to extend SANE1 just a little bit, and i dont
care if we call it SANE2 and give it a new soversion. Then, we can
spend all the time you guys want developing an extensible network
protocol, and turning saned into a real full-time daemon, because we
will have something that is easy for existing backends to use in the
meantime.
Indeed, I think the immediate future and needs are covered by
extending SANE1.

I'm focussing a bit more on the future because it's something that's
been in the air for a long time on my side, without time or incentive
to do something about it.

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Emmanuel Fust
2008-04-01 16:00:47 UTC
Permalink
Message du 01/04/08 15:03
Objet : Re: [sane-devel] SANE2 standard completion
Hello,
... I think it'd really be better to have the
frontends be entirely isolated from the backends, as I explained
already.
This would provide a central point (saned) handling the hardware
entirely
To avoid confusion with the cupsd, I like to mention that
the cupsd does not talk to the hardware (i.e. the printer).
In CUPS there are so called "backends" which talk to the
final destination of a print job (usually the printer but
often also a network service like IPP, LDP, or SMB), see
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
Furthermore I like to mention that the HP printer and scanner
driver HPLIP had in the past such a kind of daemon "hpiod"
which did the actual hardware I/O.
There have been several drawbacks with such a daemon so that
HPLIP dropped the daemon and uses now a library "libhpmud"
which does the actual hardware I/O.
I.e. perhaps in the end a library is better than a daemon?
Perhaps the crucial question is not whether the hardware I/O
is done via a library or via a daemon but to get the frontends
be entirely isolated from the backends regardless if this is
implemented via a daemon or via an additional I/O-library?
I think when a driver for all-in-one devices moved from
a daemon to a library, it might indicate that this is also
true for plain scanner drivers?
That's the point: CUPSD is a daemon regardless of implementation of the backend, daemon or I/O-lib. Nothing talk or invoke directly this io backend all talk to CUPSD via tcp or domain-unix socket in case of printing. It should be the case too for scanning via saned. io-backends should be internal API like in cups today.

Sharing problem of multifunction device is another independent one and is already a problem today without saned.
It is linked to the capability of the device (not all could do print and scan at the same time) and could be cleanly addressed and hidden in the io-backend/driver with perhaps a little bit help from the saned/cupsd side and without breaking or touching the sane client side.
Clean, simple, backward compatible and evolutive front end and backend isolation is way way simple to achieve and to maintain via a client/server based isolation than a library based isolation.
And about daemon bloat: saned job would be very simple in comparison with a complete network spooling and document printing processing system like CUPS.

Cheers,
Emmanuel.

Créez votre adresse électronique pré***@laposte.net
1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
Johannes Meixner
2008-04-02 09:38:36 UTC
Permalink
Hello,
Post by Emmanuel Fust
That's the point: CUPSD is a daemon regardless of implementation
of the backend, daemon or I/O-lib. Nothing talk or invoke directly
this io backend all talk to CUPSD via tcp or domain-unix socket
in case of printing. It should be the case too for scanning via saned.
I think I understand now what the difference is between
cupsd/saned and hpiod/libhpmud:

cupsd and saned provide a driver and frontend independent
single central service to do printing and scanning.

In contrast the hpiod was an additional special daemon
only for one single driver package (HPLIP).

It is perfectly o.k. to have central well-known daemons
like cupsd and saned to provide well-known services.

In contrast it becomes a mess when each driver package or
desktop application program or whatever program
requires its own special daemons to run to do its own
special kind of stuff.
Therefore drivers or applications or whatever programs
should not run their own daemons but use the central
well-known daemons and have their own special stuff
implemented in their own special libraries.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
Julien BLACHE
2008-04-02 17:29:48 UTC
Permalink
Johannes Meixner <***@suse.de> wrote:

Hi,
Post by Johannes Meixner
I think I understand now what the difference is between
cupsd and saned provide a driver and frontend independent
single central service to do printing and scanning.
Exactly.
Post by Johannes Meixner
In contrast the hpiod was an additional special daemon
only for one single driver package (HPLIP).
I think they used the daemon to multiplex the access to the MFP
devices, as otherwise it was not possible to print & scan "at the same
time".

JB.
--
Julien BLACHE <http://www.jblache.org>
<***@jblache.org> GPG KeyID 0xF5D65169
Continue reading on narkive:
Loading...