No subject

authorization callback. And that one is only used very seldomly
anyway.

> 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.

I have to admit that I don't understand why this helps. Well, I don't
know scheme so maybe it's quite obvious. Even if we had more than one
callback, the callback is identified by its (function) pointer. So why
do we need more than that? O haven't tried, but even if you call more
than one backend at the same time one callback per callback type
should be enough if the callback itsself is thread-safe.

> 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.

> 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 :-)

Just for the record: the SANE 1 standard is fixed, it won't be
changed. Even for SANE 2 I don't think we should make any changes that
make it more incompatible than necessary. We'll have to provide a
a sane2/sane1 meta backend and everything that introduces
incompatibilities can make that goal harder to achieve.

Bye,
  Henning