[sane-devel] Sane API Suggestion

2003-07-22 Thread abel deuring
Major A schrieb:

 The SANE API is designed to be simple and portable, and any change
 towards object orientation or functional programming would only bloat
 it unnecessarily. Sorry, if you want to interface Scheme to SANE,
 you'll have to adapt to the way things are.

Well, changing the current API is indeed not a good idea. For newer 
versions, we should be a bit more open, IMHO.

 
 Adding a callback data argument to both sane_init() and
 SANE_Authorization_Callback would cause a number of problems, in
 particular that of network transparency. Scheme or C++ programmers
 would certainly like to use that parameter as a pointer to a
 structure, but that only works if the size of the argument is at least
 that of void*. Since the latter varies across platforms, this would be
 ugly and non-portable.

I don't think that network transparency introduces a problem for user 
data pointer sizes. Since Sane itself does not deal with this pointer, 
the net backend does not need to send and receive the correct value of 
this pointer to/from the Sane server. Instead, the net backend can use 
the pointer value as passed by the application in the callback.

 
 Since the only callback in SANE is the one responsible for
 authentication, I'd say it wouldn't be worth changing anything. A
 Scheme frontend would either have to relay the authentication request
 to the user, in which case the callback data is not used, or look up
 username and password in a database, in which case the resource string
 supplied is sufficient.

Well, some time has passed sine my last look into the Sane 2 API docs, 
but IIRC it has at least one more callback.

Abel



[sane-devel] Sane API Suggestion

2003-07-21 Thread Major A
 I don't think that network transparency introduces a problem for user 
 data pointer sizes. Since Sane itself does not deal with this pointer, 
 the net backend does not need to send and receive the correct value of 
 this pointer to/from the Sane server. Instead, the net backend can use 
 the pointer value as passed by the application in the callback.

OK, you're right.

Back to the original question: I just realized that the callback
function is set when you call sane_init(), thus it must be the same
for all scanner instances. Therefore I can see little point in having
any kind of user_data since even a Scheme interface to SANE would only
use sane_init() once so it could store the user_data itself just the
same. (Unless, of course, the Scheme interface would allow for more
than one backend to be used at the same time, but with dynamic loading
etc. this would soon become a mess anyway.)

 Well, some time has passed sine my last look into the Sane 2 API docs, 
 but IIRC it has at least one more callback.

I can't remember any. The only thing that is similar in a way is the
file descriptor returned by sane_get_select_fd(), but it's not a
callback.

  Andras

===
Major Andras
e-mail: and...@users.sourceforge.net
www:http://andras.webhop.org/
===


[sane-devel] Sane API Suggestion

2003-07-20 Thread Peter Santoro
The initial version of my based application (written in scheme) does not use 
the sane api directly, but utilizes 
scanimage and scanadf to perform scanning.  In a future release, I would like 
to use the sane api directly for better 
control.

Although I have a number of years of experience programming C/C++/Java, I now 
prefer to use scheme for most of my 
programming.  After briefly looking at the sane api, I noticed that callbacks 
are sometimes used.  I am aware of a 
number of ways and various ffi libraries to handle callbacks from non-C to C, 
but it sure would be nice if the sane API 
was a little more non-C friendly.  Specifically, when a callback pointer is 
required, why not also require a user data 
void pointer (or perhaps an integer id) that would be returned untouched to the 
callback as a parameter?  This would 
allow non-C languages to interface more easily to the sane api.  A thin C 
interface layer could then use one callback 
dispatcher to handle all C callbacks.  The callback dispatcher could use 
stdarg.h to process the other args or perhaps 
they could be passed to the callback using a count and array.

In the future, I would be happy to contribute a scheme-sane interface library 
to the sane project, but it sure would be 
nice if the sane api was more non-C friendly.


Peter



[sane-devel] Sane API Suggestion

2003-07-20 Thread Henning Meier-Geinitz
Hi,

On Sun, Jul 20, 2003 at 08:48:54AM -0400, Peter Santoro wrote:
 Although I have a number of years of experience programming C/C++/Java, I 
 now prefer to use scheme for most of my programming.  After briefly looking 
 at the sane api, I noticed that callbacks are sometimes used.


[sane-devel] Sane API Suggestion

2003-07-20 Thread Henning Meier-Geinitz
Hi,

I forgot to add:

On Sun, Jul 20, 2003 at 08:48:54AM -0400, Peter Santoro wrote:
 In the future, I would be happy to contribute a scheme-sane interface 
 library to the sane project, but it sure would be nice if the sane api was 
 more non-C friendly.

I don't want to discourage you: A scheme-sane interface and
interfaces to other languages are higly appreciated. I rememebr
someone writing a C++ interface and there is a (extremely outdated)
java interface.

Bye,
  Henning


[sane-devel] Sane API Suggestion

2003-07-20 Thread Major A
  A thin C interface layer could then use one callback dispatcher to
  handle all C callbacks.  The callback dispatcher could use stdarg.h
  to process the other args or perhaps they could be passed to the
  callback using a count and array.
 
 Well, maybe the other developers have more experience with other
 languages. My first impression however, is that this makes the
 interface more complicated and complex. However, I'm no expert in
 interface design so if the other developers say it's better that way,
 I'll accept that.

Scheme is a full-blown functional language, and thus very different
from a pure procedural language. You can see from GObject (loosely
part of GTK+) how difficult it is to approach object-oriented
programming with C, and emulating functional programming in C would
certainly be totally impractical.

No C API will ever approach the full closure capabilities of Scheme,
so some sacrifices on the Scheme side must always be made when
interfacing C code.

  In the future, I would be happy to contribute a scheme-sane interface 
  library to the sane project, but it sure would be nice if the sane api was 
  more non-C friendly.
 
 Well, it's a C interface so beeing C-friendly is a feature :-)

The SANE API is designed to be simple and portable, and any change
towards object orientation or functional programming would only bloat
it unnecessarily. Sorry, if you want to interface Scheme to SANE,
you'll have to adapt to the way things are.

Adding a callback data argument to both sane_init() and
SANE_Authorization_Callback would cause a number of problems, in
particular that of network transparency. Scheme or C++ programmers
would certainly like to use that parameter as a pointer to a
structure, but that only works if the size of the argument is at least
that of void*. Since the latter varies across platforms, this would be
ugly and non-portable.

Since the only callback in SANE is the one responsible for
authentication, I'd say it wouldn't be worth changing anything. A
Scheme frontend would either have to relay the authentication request
to the user, in which case the callback data is not used, or look up
username and password in a database, in which case the resource string
supplied is sufficient.

  Andras

===
Major Andras
e-mail: and...@users.sourceforge.net
www:http://andras.webhop.org/
===