[sane-devel] SANE2 standard revisited: sane_get_select_fd

[Henning Meier-Geinitz]

Hi,

On Tue, Dec 10, 2002 at 09:42:52PM +0100, Oliver Rauch wrote:
> On Tuesday 10 December 2002 20:19, Matto Marjanovic wrote:
> 
> > A frontend which actually wants to guarantee a responsive user interface
> >  must implement its own mechanism to circumvent blocking backends.
> >  Once the frontend has this code, it no longer cares if there is support
> >  for non-blocking I/O or not.
> 
> We are just removing all possibilites for a frontend to keep the user 
> interface alive in a one-thread/one-process way by removing the select_fd and 
> the non-blocking io-mode.

It could by using the time between calling two SANE functions. It may
be not nice to call the event loop manually, but it should work.

> It is not a good API design for SANE when the frontend has to use threads or 
> subprocesses to keep the userintaface alive while using sane functions. I 
> know that it is modern to use threads but that does not mean that it is the 
> right approach to use it.

That's probably true. However, we also shouldn't move frontend
"problems" (e.g. displaying windows) to the backends. But see below:

> I suggest to keep it in the standard. It does not cost a lot for a backend
> to implement it, it does not cost anything for the API but it gives the 
> frontends more flexibility.

If it can be implemented correctly (according to the standard) I don't
mind keeping select_fd and set_io_mode. So I propose to keep it for
now and when it comes to coding sane2 frontends and sane2 backends we
check if we an follow the definition in the standard. If that works,
it's ok. Otherwise we either change or remove the two functions.

At least select_fd adds a bit of complexity to the standard. I already
mentioned the problem with the final SANE_STATUS_EOF in code flow, so
we should keep an eye on this and check for other places where it's
mentioned.

> We are just creating a "SANE standard for poor people".
> The idea of sane2 is to add more features and more flexibilty to sane.

That's one aspect. But in my opinion, we should also check if there
are aspects in SANE1, that don't work or could be made better.

The only problems I (as a backend programmer) have had with the
standard until now have been:

* cancel handling and handling of a scan that's finished (especially concerning select_fd)
* bit and byte order
* three pass scans (-> multiple frames)

> We are calling it sane2 beacause we want some extensions that are
> not compatible to sane1. In general the sane1 standard is not bad

I just want to emphasize this point a little bit more. Not counting
the above mentioned points it has been perfect for me.

> and I do not see a reason to reinvent everyting and to re-program
> everything. We should keep close to the sane1 standard when there
> is no important reason to do a change.

I don't disagree. But now is the only time to change the standard *if*
there is a real bug. So looking very closely won't hurt.

> Please also keep in mind that a sane2 frontend should be able
> to handle sane1 backends.

I'm not sure yet how this will work technically, I mean concerning
linking. Especially when we use new symbols., Does it work at all
(without a meta backend, I mean)?

Bye,
  Henning