Neither get_select_fd() nor non-blocking

> 
> there are plenty of front-ends for which non-blocking
mode is not required
> (think command line, or cgi script, etc). all of my
front-ends work this way.

You might need non-blocking with command line or cgi scripts
as well. 
Nowadays, users expects "AJAX-typ" pages, that can
load incrementally. The 
old style "read everything, write everything" is
not fun, not even with 
CGI scripts.


> if each backend (there are 68+ of them) has both a
blocking and a non-blocking
> mode, that is quite a bit of code. 

Is it, really? I haven't written a backend myself, but from
the source, 
it's not obvious that "quite a bit of code" code
be removed by removing 
the non-blocking support. 


> it is also significantly more difficult to debug the
backend when it is 
> multi-threaded. given that many of our backends are
rarely touched or 
> are maintained by someone other than the original
author, it makes sense 
> to keep them simple.

I agree, I want to make it simple, both for the backend and
application 
developers. The problem with the current situation is:

1) Backend writers "needs" to support non-blocking
and get_select_fd, 
   since the documentation says they should, and some
applications might 
   require it.

2) Application developers needs to support backends which
cannot do 
   non-blocking or get_select_fd, and must therefore use
threading/forking 
   themself. 

This seems like a lose-lose situation: Both the backend and
frontend 
developers needs to handle all three cases. Well, the
frontend developers 
could skip to try non-blocking and get_select_fd and
*always* thread/fork 
themselves. But that would mean that the
non-blocking/get_select_fd code 
in the backends are useless. So one idea is to simply make
non-blocking 
sane_read and get_select_fd deprecated, and eventually
remove them...


> besides, its easier for app developer (who likely has
multi-threading in his
> app already for other purposes) to decide that he needs
it, and deal with the
> threading himself.

Personally, I think the select loop model is superior, but
since not all 
backends supports get_select_fd, an otherwise select based
application 
might be forced to start to fork/thread. Not pretty.


> the fujitsu backend no longer has threading for this
reason.

That means that you are not following the recommendations at

http://www.cendio.se
Teknikringen 3
583 30 Linköping	Phone: +46-13-21 46 00-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

hopefully this comes thru- my sane devel mails seem to
disappear...

On Mon, 30 Oct 2006 astrandcendio.se wrote:

>> there are plenty of front-ends for which
non-blocking mode is not required
>> (think command line, or cgi script, etc). all of my
front-ends work this way.
>
> You might need non-blocking with command line or cgi
scripts as well.
> Nowadays, users expects "AJAX-typ" pages,
that can load incrementally. The
> old style "read everything, write everything"
is not fun, not even with
> CGI scripts.

ajax is beside the point. lets just say that there are apps
where 
non-blocking is not required, and apps where it is. and in
every case i 
can think of, it is the FRONTEND that has the reason for it
to be 
non-blocking.

>> if each backend (there are 68+ of them) has both a
blocking and a non-blocking
>> mode, that is quite a bit of code.
>
> Is it, really? I haven't written a backend myself, but
from the source,
> it's not obvious that "quite a bit of code"
code be removed by removing
> the non-blocking support.

perhaps we have different values for 'quite a bit'. you
obviously are a 
more accomplished programmer than me, so maybe not scared by
a few lines 
of C 

>> it is also significantly more difficult to debug
the backend when it is
>> multi-threaded. given that many of our backends are
rarely touched or
>> are maintained by someone other than the original
author, it makes sense
>> to keep them simple.
>
> I agree, I want to make it simple, both for the backend
and application
> developers. The problem with the current situation is:
>
> 1) Backend writers "needs" to support
non-blocking and get_select_fd,
>   since the documentation says they should, and some
applications might
>   require it.

no. 'A backend may elect not to support non-blocking I/O
mode' and 'A 
backend may elect not to support this operation'. they are
_optional_, and 
any application that 'requires' these in a backend is
broken.

>
> 2) Application developers needs to support backends
which cannot do
>   non-blocking or get_select_fd, and must therefore use
threading/forking
>   themself.

correct, but _only_ if he needs it for his frontend. no-one
needs to 
thread/fork if the frontend does not care to.

>
> This seems like a lose-lose situation: Both the backend
and frontend
> developers needs to handle all three cases. Well, the
frontend developers
> could skip to try non-blocking and get_select_fd and
*always* thread/fork
> themselves. But that would mean that the
non-blocking/get_select_fd code
> in the backends are useless. So one idea is to simply
make non-blocking
> sane_read and get_select_fd deprecated, and eventually
remove them...
>

my preferred solution, but i do not speak for the other
devels.

>
>> besides, its easier for app developer (who likely
has multi-threading in his
>> app already for other purposes) to decide that he
needs it, and deal with the
>> threading himself.
>
> Personally, I think the select loop model is superior,
but since not all
> backends supports get_select_fd, an otherwise select
based application
> might be forced to start to fork/thread. Not pretty.
>

in general, the backend is going to have to fork/thread to
give you your 
select_fd. i feel that the management of such OS-specific
libs, creation 
of children, dealing with signals, etc. is in the frontend.

>> the fujitsu backend no longer has threading for
this reason.
>
> That means that you are not following the
recommendations at
> lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Mon, 30 Oct 2006, m. allan noah wrote:

> > You might need non-blocking with command line or
cgi scripts as well.
> > Nowadays, users expects "AJAX-typ"
pages, that can load incrementally. The
> > old style "read everything, write
everything" is not fun, not even with
> > CGI scripts.
> 
> ajax is beside the point. lets just say that there are
apps where non-blocking
> is not required, and apps where it is. and in every
case i can think of, it is
> the FRONTEND that has the reason for it to be
non-blocking.

Yes, it is the frontend that has the need. The question is
how much 
backends should provide. In other words: Who will need to do
the hard 
work: The backend or the frontend developer? I'm not
surprised that 
backend developers wants to implement as little of the API
as possible 


> > 2) Application developers needs to support
backends which cannot do
> >   non-blocking or get_select_fd, and must
therefore use threading/forking
> >   themself.
> 
> correct, but _only_ if he needs it for his frontend.
no-one needs to
> thread/fork if the frontend does not care to.

True, you have a point here. 


> > This seems like a lose-lose situation: Both the
backend and frontend
> > developers needs to handle all three cases. Well,
the frontend developers
> > could skip to try non-blocking and get_select_fd
and *always* thread/fork
> > themselves. But that would mean that the
non-blocking/get_select_fd code
> > in the backends are useless. So one idea is to
simply make non-blocking
> > sane_read and get_select_fd deprecated, and
eventually remove them...
> >
> 
> my preferred solution, but i do not speak for the other
devels.

I think that this solution is at least better than doing
nothing at all. 
I'm positive. 


> > Personally, I think the select loop model is
superior, but since not all
> > backends supports get_select_fd, an otherwise
select based application
> > might be forced to start to fork/thread. Not
pretty.
> >
> 
> in general, the backend is going to have to fork/thread
to give you your
> select_fd. i feel that the management of such
OS-specific libs, creation of
> children, dealing with signals, etc. is in the
frontend.

You have a point. OTOH, sanei does provide this
infrastructure. 


> > I'm not really sure of what needs to be done, but
again, I believe the
> > current situation is non-optimal. Right know, I
tend to favourize this
> > solution:
> >
> > 1) Deprecate sane_set_io_mode() (and thus
non-blocking sane_read()). It
> >   doesn't give the frontend developer anything
that sane_get_select_fd()
> >   + select() doesn't give.
> >
> > 2) Make sane_get_select_fd() mandatory on UNIX.
> >
> > The only "problem" with this solution is
that the select based model
> > cannot be used on Windows, but few people wants
this anyway, they are
> > using threads instead.
> >
> 
> i would say at this point, that the only way you would
ever see that kind of
> change would be as a part of the SANE2 standard. there
are just too many
> existing backends that would have to be changed.

After looking through about 30% of the backends, I believe
you are 
correct. Most backends does not support get_select_fd(). 


> the better solution, imho, is the one taken by e.g.
XSANE. if your frontend
> cares about non-blocking mode because its a gui or
whatever, then let it deal
> with the issue. this is pretty much standard fare for
other libs for dns
> resolves, http/ftp transfers, etc. existing SANE-1
backends can drop the code
> which provides these options, and the ABI/API does not
change. SANE2 can
> remove the function calls, or leave them such that old
frontends can be easily
> ported.

For DNS resolves you have ADNS. Many HTTP libs also provides
non-blocking 
support. 

But, you have a point, I agree. libusb doesn't currenly
provide an 
asynchronous interface either. 

Regards, 
-- 
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Teknikringen 3
583 30 Linköping	Phone: +46-13-21 46 00-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Mon, 30 Oct 2006, m. allan noah wrote:

> > You might need non-blocking with command line or
cgi scripts as well.
> > Nowadays, users expects "AJAX-typ"
pages, that can load incrementally. The
> > old style "read everything, write
everything" is not fun, not even with
> > CGI scripts.
> 
> ajax is beside the point. lets just say that there are
apps where non-blocking
> is not required, and apps where it is. and in every
case i can think of, it is
> the FRONTEND that has the reason for it to be
non-blocking.

Yes, it is the frontend that has the need. The question is
how much 
backends should provide. In other words: Who will need to do
the hard 
work: The backend or the frontend developer? I'm not
surprised that 
backend developers wants to implement as little of the API
as possible 


> > 2) Application developers needs to support
backends which cannot do
> >   non-blocking or get_select_fd, and must
therefore use threading/forking
> >   themself.
> 
> correct, but _only_ if he needs it for his frontend.
no-one needs to
> thread/fork if the frontend does not care to.

True, you have a point here. 


> > This seems like a lose-lose situation: Both the
backend and frontend
> > developers needs to handle all three cases. Well,
the frontend developers
> > could skip to try non-blocking and get_select_fd
and *always* thread/fork
> > themselves. But that would mean that the
non-blocking/get_select_fd code
> > in the backends are useless. So one idea is to
simply make non-blocking
> > sane_read and get_select_fd deprecated, and
eventually remove them...
> >
> 
> my preferred solution, but i do not speak for the other
devels.

I think that this solution is at least better than doing
nothing at all. 
I'm positive. 


> > Personally, I think the select loop model is
superior, but since not all
> > backends supports get_select_fd, an otherwise
select based application
> > might be forced to start to fork/thread. Not
pretty.
> >
> 
> in general, the backend is going to have to fork/thread
to give you your
> select_fd. i feel that the management of such
OS-specific libs, creation of
> children, dealing with signals, etc. is in the
frontend.

You have a point. OTOH, sanei does provide this
infrastructure. 


> > I'm not really sure of what needs to be done, but
again, I believe the
> > current situation is non-optimal. Right know, I
tend to favourize this
> > solution:
> >
> > 1) Deprecate sane_set_io_mode() (and thus
non-blocking sane_read()). It
> >   doesn't give the frontend developer anything
that sane_get_select_fd()
> >   + select() doesn't give.
> >
> > 2) Make sane_get_select_fd() mandatory on UNIX.
> >
> > The only "problem" with this solution is
that the select based model
> > cannot be used on Windows, but few people wants
this anyway, they are
> > using threads instead.
> >
> 
> i would say at this point, that the only way you would
ever see that kind of
> change would be as a part of the SANE2 standard. there
are just too many
> existing backends that would have to be changed.

After looking through about 30% of the backends, I believe
you are 
correct. Most backends does not support get_select_fd(). 


> the better solution, imho, is the one taken by e.g.
XSANE. if your frontend
> cares about non-blocking mode because its a gui or
whatever, then let it deal
> with the issue. this is pretty much standard fare for
other libs for dns
> resolves, http/ftp transfers, etc. existing SANE-1
backends can drop the code
> which provides these options, and the ABI/API does not
change. SANE2 can
> remove the function calls, or leave them such that old
frontends can be easily
> ported.

For DNS resolves you have ADNS. Many HTTP libs also provides
non-blocking 
support. 

But, you have a point, I agree. libusb doesn't currenly
provide an 
asynchronous interface either. 

Regards, 
-- 
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Teknikringen 3
583 30 Linköping	Phone: +46-13-21 46 00-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Tue, 31 Oct 2006 astrandcendio.se wrote:

> On Mon, 30 Oct 2006, m. allan noah wrote:

...snip...

>>> Personally, I think the select loop model is
superior, but since not all
>>> backends supports get_select_fd, an otherwise
select based application
>>> might be forced to start to fork/thread. Not
pretty.
>>>
>>
>> in general, the backend is going to have to
fork/thread to give you your
>> select_fd. i feel that the management of such
OS-specific libs, creation of
>> children, dealing with signals, etc. is in the
frontend.
>
> You have a point. OTOH, sanei does provide this
infrastructure.

unfortunately, it does not provide it all that well. there
were some 
discussions here lately about certain backends 'hijacking'
the frontend's 
signals. i cant remember the specifics, off hand. but it
would be good for 
the frontend developer who develops using a non-signaling
backend, if all 
the backends did not use signals. then he does not get
bitten by this 
problem when one of his users uses another backend that does
use signals.

...snip...

>> the better solution, imho, is the one taken by e.g.
XSANE. if your frontend
>> cares about non-blocking mode because its a gui or
whatever, then let it deal
>> with the issue. this is pretty much standard fare
for other libs for dns
>> resolves, http/ftp transfers, etc. existing SANE-1
backends can drop the code
>> which provides these options, and the ABI/API does
not change. SANE2 can
>> remove the function calls, or leave them such that
old frontends can be easily
>> ported.
>
> For DNS resolves you have ADNS. Many HTTP libs also
provides non-blocking
> support.
>
> But, you have a point, I agree. libusb doesn't currenly
provide an
> asynchronous interface either.
>

yes, there are plenty of counter examples (c-ares), and some
even do both 
(libcurl). but in general, these tend to be projects that
support a few 
protocols in a single library, with a single point of entry
into the ABI.

Sane is much more fragmented. Anything that brings
consistency to sane is 
better for front-end devels. The easiest way to get there is
to remove 
code, not add it 

allan

-- 
"so don't tell us it can't be done, putting down what
you don't know.
money isn't our god, integrity will free our souls" -
Max Cavalera

-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Tue, 31 Oct 2006 astrandcendio.se wrote:

> On Mon, 30 Oct 2006, m. allan noah wrote:

...snip...

>>> Personally, I think the select loop model is
superior, but since not all
>>> backends supports get_select_fd, an otherwise
select based application
>>> might be forced to start to fork/thread. Not
pretty.
>>>
>>
>> in general, the backend is going to have to
fork/thread to give you your
>> select_fd. i feel that the management of such
OS-specific libs, creation of
>> children, dealing with signals, etc. is in the
frontend.
>
> You have a point. OTOH, sanei does provide this
infrastructure.

unfortunately, it does not provide it all that well. there
were some 
discussions here lately about certain backends 'hijacking'
the frontend's 
signals. i cant remember the specifics, off hand. but it
would be good for 
the frontend developer who develops using a non-signaling
backend, if all 
the backends did not use signals. then he does not get
bitten by this 
problem when one of his users uses another backend that does
use signals.

...snip...

>> the better solution, imho, is the one taken by e.g.
XSANE. if your frontend
>> cares about non-blocking mode because its a gui or
whatever, then let it deal
>> with the issue. this is pretty much standard fare
for other libs for dns
>> resolves, http/ftp transfers, etc. existing SANE-1
backends can drop the code
>> which provides these options, and the ABI/API does
not change. SANE2 can
>> remove the function calls, or leave them such that
old frontends can be easily
>> ported.
>
> For DNS resolves you have ADNS. Many HTTP libs also
provides non-blocking
> support.
>
> But, you have a point, I agree. libusb doesn't currenly
provide an
> asynchronous interface either.
>

yes, there are plenty of counter examples (c-ares), and some
even do both 
(libcurl). but in general, these tend to be projects that
support a few 
protocols in a single library, with a single point of entry
into the ABI.

Sane is much more fragmented. Anything that brings
consistency to sane is 
better for front-end devels. The easiest way to get there is
to remove 
code, not add it 

allan

-- 
"so don't tell us it can't be done, putting down what
you don't know.
money isn't our god, integrity will free our souls" -
Max Cavalera

-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org