[sane-devel] SANE2 standard completion

[Rene Rebe]

On 10.04.2008, at 21:33, stef wrote:

> Le Wednesday 09 April 2008 21:38:26, vous avez ?crit :
>>
>> 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

[sane-devel] SANE2 standard completion

[stef]

Le Wednesday 09 April 2008 21:38:26, vous avez ?crit?:
>
> 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

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 09.04.2008, at 21:27, stef wrote:

> Le Wednesday 09 April 2008 12:48:22 Ren? Rebe, vous avez ?crit :
>
>>
>> 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

[sane-devel] SANE2 standard completion

[stef]

Le Wednesday 09 April 2008 12:48:22 Ren? Rebe, vous avez ?crit?:

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

[sane-devel] SANE2 standard completion

[René Rebe]

Hi,

stef wrote:
> Le Sunday 06 April 2008 21:16:44 m. allan noah, vous avez ?crit :
>> On 3/28/08, Rene Rebe  wrote:
>   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
 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

[sane-devel] SANE2 standard completion

[stef]

Le Sunday 06 April 2008 21:16:44 m. allan noah, vous avez ?crit?:
> On 3/28/08, Rene Rebe  wrote:
> > > >   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
> > >
> > > 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.

> 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

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

Lei Chen  wrote:

Hi,

>> agreed. if i were to make sane2 myself, i would change the license to
>> straight GPL3.
>
> Why not LGPL? Is LGPL not so straight for libraries and dynamic
> objects? The current license makes thing complex. People have to pay
> close attention to GPL libraries and backends, with or without that
> exception claiming, in SANE.

All backends in SANE are GPL + exception, which is roughly equivalent
to the LGPL.

Relicensing SANE is not possible, because quite a few copyright
holders cannot be reached to obtain permission.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Lei Chen]

m. allan noah wrote:
> On 4/2/08, Olaf Meeuwissen  wrote:
>   
>>
>>
>> If you want to interpret it like that fine, but all the SANE backends
>>  that use the exception mechanism explained in the LICENSE file are per
>>  same token decidedly NOT free-as-in-freedom.  That includes, at least,
>>  the dll, net and epson backends as well as all the backends that you
>>  contributed to.
>> 
>
> agreed. if i were to make sane2 myself, i would change the license to
> straight GPL3.
>   
Why not LGPL? Is LGPL not so straight for libraries and dynamic objects? 
The current license makes thing complex. People have to pay close 
attention to GPL libraries and backends, with or without that exception 
claiming, in SANE.

Regards,
Lei Chen

>   
>>  FYI, the LICENSE file says:
>> 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080408/df73ccac/attachment.htm
 

[sane-devel] SANE2, what do we want ?

[m. allan noah]

On Tue, Apr 8, 2008 at 12:52 PM, Julien BLACHE  wrote:
> Lei Chen  wrote:
>
>  Hi,
>
>
>  >> agreed. if i were to make sane2 myself, i would change the license to
>  >> straight GPL3.
>  >
>  > Why not LGPL? Is LGPL not so straight for libraries and dynamic
>  > objects? The current license makes thing complex. People have to pay
>  > close attention to GPL libraries and backends, with or without that
>  > exception claiming, in SANE.
>
>  All backends in SANE are GPL + exception, which is roughly equivalent
>  to the LGPL.
>
>  Relicensing SANE is not possible, because quite a few copyright
>  holders cannot be reached to obtain permission.
>
>

Julien is correct of course, but you asked why would i do that if i
had the chance?

Because we are routinely asked about things like descreening or color
correction- problems which have been solved long ago, with code that
is now lost to us, because it was only delivered as a binary.
Reinventing the wheel over and over, just because some now-dead
company decided that some text was secret is a stupid waste of human
resources.

Using the LGPL allows that trend to continue, with proprietary
front-ends, and proprietary backend 'plugins'.

allan
--
"The truth is an offense, but not a sin"

[sane-devel] SANE2, what do we want ?

[Olaf Meeuwissen]

Julien BLACHE  writes:

> Olaf Meeuwissen  wrote:
>
> Hi,
>
>>> Not exactly free by my book, I'm sorry but it really does make a
>>> difference.
>>
>> As free as the epkowa backend software is concerned, it is free.  The
>> fact that it does not support all the scanner models you would like it
>> to without a non-free extension does not change anything to the fact
>> that the backend software is free-as-in-freedom.
>
> You can disagree all you want, I'm pretty sure the FSF stands on my
> side.

The FSF will very likely concede the fact that the backend is free to
the letter of the license.  At the same time, they will very likely
remark that the backend is not really free in spirit.  AFAIK, the FSF
has always allowed (but not encouraged) inter-operation with non-free
components.  The GPL FAQ includes explanations for several scenarios
that want to cater to non-free extensions or use non-free components.

>>> The udev rules in libsane-extras were buggy; it was absolutely harmless
>>> until I migrated to a new layout for installing udev rules, then all
>>> hell broke loose and the only option to avoid rendering systems
>>> unbootable was to have that dependency.
>>
>> Why was that the only option?  If thee udev rules in libsane-extras
>> were buggy, why could you not fix that?
>
> Because that by itself doesn't fix the problem on systems where
> libsane-extras is removed but not purged. Hence the dependency was
> needed to reinstall libsane-extras with a fixed rules file on those
> systems.
>
> This change will be reverted after the Lenny release.

I see but don't quite understand so I'll take a look later.

> [snip]
>>> Use a diversion on libsane-epkowa.* to handle that, that's the best
>>> option.
>>
>> What about suggestions for the conffile?  I was gonna put them in
>> dll.d but that doesn't look as attractive as it did before
>> libsane-extras became a Depends:.
>
> You can divert the conffile, too.

Considering the fact that iscan and libsane-extras will be stepping on
each other's toes in this area (as far as the backends are concerned),
we should probably work something out.  IIRC, diversions require
mutual agreement on both sides.  We can do this off-list.

>> With 12 interpreters at the moment (and counting :-() and the need to
>> cater to two C++ ABIs, the non-free interpreters, which are only
>> needed by a select few people to begin with (and even fewer will need
>> all the interpreters) would bloat the packages out of any proportion.
>
> I understand perfectly, I also understand that there's nothing
> preventing them from giving access to the directory on the webserver
> where the packages are stored so it's possible to retrieve them all in
> one go if needed.

In terms of technology, you are absolutely right.  We could even set
up repositories so you could just use apt-get or yum to install iscan.
Unfortunately, technology does have the final say in this issue.

Hope this helps,
-- 
Olaf Meeuwissen   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962   sign up at http://member.fsf.org/

[sane-devel] SANE2, what do we want ?

[Olaf Meeuwissen]

Julien BLACHE  writes:

> Olaf Meeuwissen  wrote:
>
>> The epkowa backend is free-as-in-freedom software.  It is licensed
>> under the terms of the GPL and carries an exception that allows for
>> the use of non-free extensions.
>
> "It's free software (but for this and this and this and this model you
> need a binary-only, proprietary lib, too)"
>
> Not exactly free by my book, I'm sorry but it really does make a
> difference.

As free as the epkowa backend software is concerned, it is free.  The
fact that it does not support all the scanner models you would like it
to without a non-free extension does not change anything to the fact
that the backend software is free-as-in-freedom.

> [snip]
>
>> Not claiming that the epkowa backend does a perfect job either, but
>> at least the epson backend does not support a number of all-in-ones.
>
> TTOMK the all-in-ones are all pretty similar devices?

Mostly yes, but the epson backend does not support all of the commands
these devices understand completely.

I remember trying the epson backend at home with an RX520 (PM-A750)
and not being able to scan.  FWIW, I can't use iscan at home because
there are no amd64 Debian packages ;-P

> [snip]
>
>> BTW, many thanks for packaging the epkowa backend in libsane-extras
>> for Debian ;-) but can you tell me why libsane has to depend on it?
>> What breaks in libsane if I yank libsane-extras?
>
> The udev rules in libsane-extras were buggy; it was absolutely harmless
> until I migrated to a new layout for installing udev rules, then all
> hell broke loose and the only option to avoid rendering systems
> unbootable was to have that dependency.

Why was that the only option?  If thee udev rules in libsane-extras
were buggy, why could you not fix that?

If libsane no longer works because libsane-extras is not installed,
then they aren't exactly "extras" in my book ;-)

> And now I no longer have to ask "do you have libsane-extras
> installed?" in bug reports, which is a selling point, really ;)

But that's just convenience.  Rather than Depends: you could have made
it a Recommends:.

>> # We're about to start providing Image Scan! for Linux .debs and this
>> # is a bit of a show-stopper conflict ...
>
> Use a diversion on libsane-epkowa.* to handle that, that's the best
> option.

What about suggestions for the conffile?  I was gonna put them in
dll.d but that doesn't look as attractive as it did before
libsane-extras became a Depends:.

> Note that I would have packaged iScan, had Epson provided a tarball
> with all the interpreters libraries.

Splitting the interpreters off from the source and binary packages was
done to reduce package size and to clearly separate free and non-free
code.  Only the non-free bits needed to build to frontend are included
in the "sources".

With 12 interpreters at the moment (and counting :-() and the need to
cater to two C++ ABIs, the non-free interpreters, which are only
needed by a select few people to begin with (and even fewer will need
all the interpreters) would bloat the packages out of any proportion.

> As it stands, I once managed to grab all the RPMs by playing with
> the webserver but:
>  - no way I was going to do that long-term

Very understandable.

>  - no way I am extracting the files from a collection of RPMs every
>time

Apart from the interpreters, which files, if any?  Everything is in
the "source" tarball, AFAIK.

>  - redistribution is prohibited IIRC

You recall incorrectly.  Redistribution is allowed.  Modification is
allowed too.  Just about the only thing you are not allowed to do is
reverse engineering (unless for the purposes of debugging your own
applications/modifications -- a LGPL requirement).

Hope this helps,
-- 
Olaf Meeuwissen   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962   sign up at http://member.fsf.org/

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

Olaf Meeuwissen  wrote:

Hi,

>> Not exactly free by my book, I'm sorry but it really does make a
>> difference.
>
> As free as the epkowa backend software is concerned, it is free.  The
> fact that it does not support all the scanner models you would like it
> to without a non-free extension does not change anything to the fact
> that the backend software is free-as-in-freedom.

You can disagree all you want, I'm pretty sure the FSF stands on my
side.

>> The udev rules in libsane-extras were buggy; it was absolutely harmless
>> until I migrated to a new layout for installing udev rules, then all
>> hell broke loose and the only option to avoid rendering systems
>> unbootable was to have that dependency.
>
> Why was that the only option?  If thee udev rules in libsane-extras
> were buggy, why could you not fix that?

Because that by itself doesn't fix the problem on systems where
libsane-extras is removed but not purged. Hence the dependency was
needed to reinstall libsane-extras with a fixed rules file on those
systems.

This change will be reverted after the Lenny release.

> If libsane no longer works because libsane-extras is not installed,
> then they aren't exactly "extras" in my book ;-)

The package is only separated from libsane because I wanted a small
independent source package that I could upload as frequently as I
wanted without overloading our buildd infrastructure with something as
big as libsane.

>> And now I no longer have to ask "do you have libsane-extras
>> installed?" in bug reports, which is a selling point, really ;)
>
> But that's just convenience.  Rather than Depends: you could have made
> it a Recommends:.

Obviously the wording and smiley weren't enough, I'll use XML markup
next time :-/

>> Use a diversion on libsane-epkowa.* to handle that, that's the best
>> option.
>
> What about suggestions for the conffile?  I was gonna put them in
> dll.d but that doesn't look as attractive as it did before
> libsane-extras became a Depends:.

You can divert the conffile, too.

> With 12 interpreters at the moment (and counting :-() and the need to
> cater to two C++ ABIs, the non-free interpreters, which are only
> needed by a select few people to begin with (and even fewer will need
> all the interpreters) would bloat the packages out of any proportion.

I understand perfectly, I also understand that there's nothing
preventing them from giving access to the directory on the webserver
where the packages are stored so it's possible to retrieve them all in
one go if needed.

>>  - no way I am extracting the files from a collection of RPMs every
>>time
>
> Apart from the interpreters, which files, if any?  Everything is in
> the "source" tarball, AFAIK.

Nothing else, only the interpreters.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[m. allan noah]

On 3/28/08, Rene Rebe  wrote:
> > >   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
> > >
> > >
> >
> > 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"

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

"m. allan noah"  wrote:

>>  >> Call ECMA and ISO, we need a fast-track for SANE1.
>>  > Do you have the money for that :-). Biggest problem is MS. Have to ask 
>> Bill
>>  > for permission to fast track it :-)
>>
>>  Maybe the MS/Novell agreement can help?
>
> foul- thats below the belt :)

>:->

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Alessandro Zummo]

On Wed, 02 Apr 2008 19:26:53 +0200
Julien BLACHE  wrote:


> >  I believe RMS could kill should he read the exception that
> >  allows linking a closed source frontend to a backend.. :)
> 
> So he would commit suicide reading the LGPL? :)

 Don't tell him, he might do it :-D


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

Sigurd Stordal  wrote:

>> Call ECMA and ISO, we need a fast-track for SANE1.
> Do you have the money for that :-). Biggest problem is MS. Have to ask Bill 
> for permission to fast track it :-)

Maybe the MS/Novell agreement can help?

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Sigurd Stordal]

On Wednesday 02 April 2008 19:28:19 Julien BLACHE wrote:
> Johannes Meixner  wrote:
>
> Hi,
>
> > Currently SANE1 is only internally (i.e. within the SANE project)
> > a standard, but from the outer world there is no confirmation
> > that one can rely on SANE1 for the near future, see (*) above.
>
> Call ECMA and ISO, we need a fast-track for SANE1.
Do you have the money for that :-). Biggest problem is MS. Have to ask Bill 
for permission to fast track it :-)
-- 
Opuskreator ad laur. VVSOP Grand Cru I of DNM 95
(The Norwegian Male Choir of 1995)

[sane-devel] SANE2 standard completion

[Julien BLACHE]

Johannes Meixner  wrote:

Hi,

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

Exactly.

> 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    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

Johannes Meixner  wrote:

Hi,

> Currently SANE1 is only internally (i.e. within the SANE project)
> a standard, but from the outer world there is no confirmation
> that one can rely on SANE1 for the near future, see (*) above.

Call ECMA and ISO, we need a fast-track for SANE1.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

Alessandro Zummo  wrote:

Hi,

>  I believe RMS could kill should he read the exception that
>  allows linking a closed source frontend to a backend.. :)

So he would commit suicide reading the LGPL? :)

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

"m. allan noah"  wrote:

Hi,

> IMHO, that exception was to allow proprietary front-ends, not backend
> pieces. Specifically the use of the the term 'link against such a
> library', implies that proprietary code could dlopen a backend, but
> not that the backend could dlopen a proprietary library, which we see
> with various external backends.

Olaf, the above paragraph is absolutely correct, and you interpreted
the license backwards.

The SANE license (GPL + exception) was designed before the LGPL was
written; it's roughly equivalent to the LGPL in its intent.

This has been discussed on this list already, with Henning telling
just what I wrote.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

Olaf Meeuwissen  wrote:

Hi,

> The epkowa backend is free-as-in-freedom software.  It is licensed
> under the terms of the GPL and carries an exception that allows for
> the use of non-free extensions.

"It's free software (but for this and this and this and this model you
need a binary-only, proprietary lib, too)"

Not exactly free by my book, I'm sorry but it really does make a
difference.

> Of the 181 models (by market name) supported by the backend 35 require
> such a non-free extension.
>
> # Unfortunately, an increasing proportion of the recents models
> # requires one.

And I'm saying all that with that knowledge, as we discussed epkowa
quite a few times :)

> Not claiming that the epkowa backend does a perfect job either, but
> at least the epson backend does not support a number of all-in-ones.

TTOMK the all-in-ones are all pretty similar devices?

> Moreover, and in case you missed this, the epson backend is _not_
> maintained anymore.

I didn't miss it, but AFAIK epson2 supports everything supported by
epson and more.

> BTW, many thanks for packaging the epkowa backend in libsane-extras
> for Debian ;-) but can you tell me why libsane has to depend on it?
> What breaks in libsane if I yank libsane-extras?

The udev rules in libsane-extras were buggy; it was absolutely harmless
until I migrated to a new layout for installing udev rules, then all
hell broke loose and the only option to avoid rendering systems
unbootable was to have that dependency.

And now I no longer have to ask "do you have libsane-extras
installed?" in bug reports, which is a selling point, really ;)

> # We're about to start providing Image Scan! for Linux .debs and this
> # is a bit of a show-stopper conflict ...

Use a diversion on libsane-epkowa.* to handle that, that's the best
option.

Note that I would have packaged iScan, had Epson provided a tarball
with all the interpreters libraries. As it stands, I once managed to
grab all the RPMs by playing with the webserver but:
 - no way I was going to do that long-term
 - no way I am extracting the files from a collection of RPMs every time
 - redistribution is prohibited IIRC

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Olaf Meeuwissen]

"m. allan noah"  writes:

> On 4/1/08, Olaf Meeuwissen  wrote:
>> Julien BLACHE  writes:
>>
>>  > Johannes Meixner  wrote:
>>
>> >> For example the epkowa driver from IScan is free software.
>>  >
>>  > No, epkowa is not free software. A large part of the scanners it
>>  > supports actually rely on proprietary, binary-only protocol
>>  > interpreters shipped as Linux/i386 shared libraries.
>>
>>
>> The epkowa backend is free-as-in-freedom software.  It is licensed
>>  under the terms of the GPL and carries an exception that allows for
>>  the use of non-free extensions.
>
> well, i just heard RMS speak again a few days ago, and i can tell you
> for sure that this exception means the backend is decidedly NOT
> free-as-in-freedom. we could take it up with him if you like...

If you want to interpret it like that fine, but all the SANE backends
that use the exception mechanism explained in the LICENSE file are per
same token decidedly NOT free-as-in-freedom.  That includes, at least,
the dll, net and epson backends as well as all the backends that you
contributed to.

FYI, the LICENSE file says:

Backend libraries are protected by the GNU General Public License (see
file COPYING), but as an exception, it is permissible to link against
such a library without affecting the licensing status of the program
that uses the libraries.  For details, see the copyright notice at the
head of the backend files (e.g., backend/dll.c).

and it is this mechanism that the epkowa backend uses.  As a matter of
fact, the code interfacing between the free and non-free parts is even
stricter in that it only allows linking through a carefully defined
API.

Moreover, the epkowa backend does not require the non-free extensions.

On a strictly personal note: I'd very much like to see those non-free
extensions to the epkowa backend become a thing of the past.

Hope this helps,
-- 
Olaf Meeuwissen   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962   sign up at http://member.fsf.org/

[sane-devel] SANE2, what do we want ?

[m. allan noah]

On Wed, Apr 2, 2008 at 3:18 PM, Julien BLACHE  wrote:
> Sigurd Stordal  wrote:
>
>  >> Call ECMA and ISO, we need a fast-track for SANE1.
>  > Do you have the money for that :-). Biggest problem is MS. Have to ask Bill
>  > for permission to fast track it :-)
>
>  Maybe the MS/Novell agreement can help?

foul- thats below the belt :)

allan
-- 
"The truth is an offense, but not a sin"

[sane-devel] SANE2 standard completion

[Johannes Meixner]

Hello,

On Apr 1 18:00 Emmanuel Fust wrote (shortened):
> 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

[sane-devel] SANE2, what do we want ?

[Johannes Meixner]

Hello,

On Apr 2 15:49 Olaf Meeuwissen wrote (shortened):
> ... the epkowa backend does not require the non-free extensions.

As far as I understand the license stuff, this is the crucial
condition whether or not some piece of software can be under GPL
even if it "uses" some non-free additional module.

The epkowa backend is useful for many scanners without
the non-free extensions.
Therefore is does not necessarily "link" with non-free stuff.
Therefore it is a stand-alone-usable free software.
Therefore it can be under GPL.

This license issue is another item why drivers (backends)
and applications (frontends) should be better isolated
from each other.

Currently frontends link with libsane which links with libdriver
which may link with libdrivermodule which is only clean GPL
if all parts are under the same GPL version.

But as soon as there are differnt licenses (from incompatible
free software licenses up to proprietary software licenses)
the mess starts.

If the frontend would not link with libsane but talk to saned
via whatever protocol and if saned would not link with libdriver
but talk to the driver via whatever protocol, every part could
be under whatever license.

Of course such a loose coupling is perfect for any kind
of non-free drivers and non-free frontends ;-)

But another big advantage of such a loose coupling is
that broken drivers (aka. "non-free drivers" ;-)
cannot hurt the rest of the scanning system (saned + frontend)
provided the "whatever protocol" implementation is fail-safe: 

A few days ago I had accidentally messed up my SANE drivers
with one broken driver which did a segfault.
Because of the current linking, "scanimage -L" segfaults too
regardless that I have several other scanners and drivers
which could work well.

 
> On a strictly personal note: I'd very much like to see those non-free
> extensions to the epkowa backend become a thing of the past.

Isn't the reason for non-free extensions often third-party
licenses which make it impossible for the manufacturer
to make a free driver even if he likes to do?

For example printers which need a JBIG data compression to send
printing data to the printer (so called ZJStream printers):

JBIG data compression has patent issues which makes it
impossible to make a free driver for ZJStream printers
which is the reason why even HPLIP must use additional
proprietary modules for certain printers, see for example
https://bugzilla.novell.com/show_bug.cgi?id=342704
in particular
https://bugzilla.novell.com/show_bug.cgi?id=342704#c1
and
https://bugzilla.novell.com/show_bug.cgi?id=342704#c3

Of course very many users out there in the real world
blindly buy ZJStream printers because they are cheap
(i.e. get many dots per inch for less money ;-)
and I guess it is the same for Epson scanners which
require a non-free module which adds another layer
to the whole problem:

Should we repel such users ("you get what you paid for")
and accept that Linux doesn't become very popular
or should we swallow the bitter pill for the sake of
making Linux more popular?

My strictly personal opinion is:
I accept optional additional non-free modules for free software
(i.e. the non-free modules for the epkowa and hpaio drivers
or for example the Adobe Reader plugin for free browsers)
but I do not accept non-free software (i.e. which is useless
without non-free stuff).


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex

[sane-devel] SANE2, what do we want ?

[Johannes Meixner]

Hello,

On Apr 1 18:36 Julien BLACHE wrote (shortened):
> I think SANE1 has proved its stability over the years now.

The way how the discussion regarding SANE2 is done
could indicate exactly the opposite for the future (*)
for someone at a manufacturer who listens to this
discussion to decide whether or not to make a Linux driver.

But when SANE1 would be stable even for the future,
what would be a real drawback when it also becomes
a LSB standard?

I don't think a LSB standard attracts more proprietary stuff.
I think it is the opposite:

I think if a manufacturer decides to do his stuff isolated
from the rest of the world (i.e. make their usual proprietary
nonsense), they will make their usual proprietary bloatware
driver packages (inlude all what they decide which makes users
happy: backend + frontend + tools + installer-script + ...)
regardless of what the rest of the world really needs.

I think if SANE1 was a LSB standard, more manufacturers decide
to give up their isolation and listen to what the world really
likes to have which results more free driver packages which
are designed in compliance to the standard.


Another item why SANE1 should become a LSB standard:

Currently SANE1 is no official standard from the "outer world
point of view" - I mean no standard which is declared to be a
standard by an independent organization.

Currently SANE1 is only internally (i.e. within the SANE project)
a standard, but from the outer world there is no confirmation
that one can rely on SANE1 for the near future, see (*) above.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex

[sane-devel] SANE2, what do we want ?

[m. allan noah]

On 4/2/08, Olaf Meeuwissen  wrote:
> "m. allan noah"  writes:
>
>  > On 4/1/08, Olaf Meeuwissen  wrote:
>  >> Julien BLACHE  writes:
>  >>
>  >>  > Johannes Meixner  wrote:
>  >>
>  >> >> For example the epkowa driver from IScan is free software.
>  >>  >
>  >>  > No, epkowa is not free software. A large part of the scanners it
>  >>  > supports actually rely on proprietary, binary-only protocol
>  >>  > interpreters shipped as Linux/i386 shared libraries.
>  >>
>  >>
>  >> The epkowa backend is free-as-in-freedom software.  It is licensed
>  >>  under the terms of the GPL and carries an exception that allows for
>  >>  the use of non-free extensions.
>  >
>  > well, i just heard RMS speak again a few days ago, and i can tell you
>  > for sure that this exception means the backend is decidedly NOT
>  > free-as-in-freedom. we could take it up with him if you like...
>
>
> If you want to interpret it like that fine, but all the SANE backends
>  that use the exception mechanism explained in the LICENSE file are per
>  same token decidedly NOT free-as-in-freedom.  That includes, at least,
>  the dll, net and epson backends as well as all the backends that you
>  contributed to.

agreed. if i were to make sane2 myself, i would change the license to
straight GPL3.

>  FYI, the LICENSE file says:
>
> Backend libraries are protected by the GNU General Public License (see
> file COPYING), but as an exception, it is permissible to link against
> such a library without affecting the licensing status of the program
> that uses the libraries.  For details, see the copyright notice at the
> head of the backend files (e.g., backend/dll.c).
>
>  and it is this mechanism that the epkowa backend uses.

IMHO, that exception was to allow proprietary front-ends, not backend
pieces. Specifically the use of the the term 'link against such a
library', implies that proprietary code could dlopen a backend, but
not that the backend could dlopen a proprietary library, which we see
with various external backends.

i suppose you could get around that by having iscan do the opening of
the binary 'translator', and then _that_ could dlopen the backend, but
reversing the order would seem to violate the license.

this ambiguity would be removed (and user's freedoms better protected)
if that license exception was dropped. If we still wish to support
proprietary front-ends, a defined network protocol would be the safest
method. Proprietary backends could then be a separate debate, perhaps
with something like the linux kernel's 'tainted' mechanism? (or my
preference, to refuse to load them ;)

allan

allan

-- 
"The truth is an offense, but not a sin"

[sane-devel] SANE2, what do we want ?

[Alessandro Zummo]

On Tue, 1 Apr 2008 21:45:25 -0400
"m. allan noah"  wrote:

> > The epkowa backend is free-as-in-freedom software.  It is licensed
> >  under the terms of the GPL and carries an exception that allows for
> >  the use of non-free extensions.
> 
> well, i just heard RMS speak again a few days ago, and i can tell you
> for sure that this exception means the backend is decidedly NOT
> free-as-in-freedom. we could take it up with him if you like...

 I believe RMS could kill should he read the exception that
 allows linking a closed source frontend to a backend.. :)

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] SANE2, what do we want ?

[Olaf Meeuwissen]

Julien BLACHE  writes:

> Johannes Meixner  wrote:
>> For example the epkowa driver from IScan is free software.
>
> No, epkowa is not free software. A large part of the scanners it
> supports actually rely on proprietary, binary-only protocol
> interpreters shipped as Linux/i386 shared libraries.

The epkowa backend is free-as-in-freedom software.  It is licensed
under the terms of the GPL and carries an exception that allows for
the use of non-free extensions.

Of the 181 models (by market name) supported by the backend 35 require
such a non-free extension.

# Unfortunately, an increasing proportion of the recents models
# requires one.

> If you don't need to use such a scanner, then you don't need to bother
> with epkowa, as your scanner is pretty much for sure supported by
> either epson, epson2 or snapscan.

Not claiming that the epkowa backend does a perfect job either, but
at least the epson backend does not support a number of all-in-ones.
Moreover, and in case you missed this, the epson backend is _not_
maintained anymore.

BTW, many thanks for packaging the epkowa backend in libsane-extras
for Debian ;-) but can you tell me why libsane has to depend on it?
What breaks in libsane if I yank libsane-extras?
# We're about to start providing Image Scan! for Linux .debs and this
# is a bit of a show-stopper conflict ...

Hope this helps,
-- 
Olaf Meeuwissen   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962   sign up at http://member.fsf.org/

[sane-devel] SANE2, what do we want ?

[m. allan noah]

On 4/1/08, Olaf Meeuwissen  wrote:
> Julien BLACHE  writes:
>
>  > Johannes Meixner  wrote:
>
> >> For example the epkowa driver from IScan is free software.
>  >
>  > No, epkowa is not free software. A large part of the scanners it
>  > supports actually rely on proprietary, binary-only protocol
>  > interpreters shipped as Linux/i386 shared libraries.
>
>
> The epkowa backend is free-as-in-freedom software.  It is licensed
>  under the terms of the GPL and carries an exception that allows for
>  the use of non-free extensions.

well, i just heard RMS speak again a few days ago, and i can tell you
for sure that this exception means the backend is decidedly NOT
free-as-in-freedom. we could take it up with him if you like...

allan
-- 
"The truth is an offense, but not a sin"

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

Johannes Meixner  wrote:

Hi,

> Did Till write that the LSB standard applies only for
> broken binary drivers?

The LSB tries to ensure binary compatibility between distributions,
which very obviously benefits more to proprietary crap than anything
else?

> For example the epkowa driver from IScan is free software.

No, epkowa is not free software. A large part of the scanners it
supports actually rely on proprietary, binary-only protocol
interpreters shipped as Linux/i386 shared libraries.

If you don't need to use such a scanner, then you don't need to bother
with epkowa, as your scanner is pretty much for sure supported by
either epson, epson2 or snapscan.

> I would appreciate it if there were more free drivers from
> manufacturers but manufacturers ask for reliable standards.
> If SANE1 was LSB, there would be such a reliable standard.

I think SANE1 has proved its stability over the years now. This is
nothing else than a very poor excuse for manufacturers.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Julien BLACHE]

Johannes Meixner  wrote:

Hi,

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

Same for saned.

> 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    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Emmanuel Fust]

> Message du 01/04/08 15:03
> De : "Johannes Meixner" 
> A : sane-devel at lists.alioth.debian.org
> Copie ? : 
> Objet : Re: [sane-devel] SANE2 standard completion
>
> 
> Hello,
> 
> On Mar 28 18:40 Julien BLACHE wrote (shortened):
> > ... 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?nom.nom at laposte.net 
 1 Go d'espace de stockage, anti-spam et anti-virus int?gr?s.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080401/e3450454/attachment.htm
 

[sane-devel] SANE2 standard completion

[Johannes Meixner]

Hello,

On Mar 28 19:13 Julien BLACHE wrote (shortened):
> ... 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

[sane-devel] SANE2, what do we want ?

[Johannes Meixner]

Hello,

On Mar 28 22:49 Julien BLACHE wrote:
> Till Kamppeter  wrote:
> 
> > ago and no one answered). This will help us that it is much easier for 
> > scanner manufacturers to ship drivers with their scanners. They can 
> 
> This is all but a good thing. Currently, binary backends provided by
> the manufacturers are nothing more than a total annoyance.
> 
> They're crappy, non-debuggable, under-documented, badly written, badly
> tested, and available for Linux/i386 only.
> 
> Encouraging binary backends undermines the efforts done by backends
> developers over the past years to obtain specification/documentation
> from the manufacturers.
> 
> Think twice, please. You're actually actively harming both SANE and
> the users by doing so.

Could you please avoid such harsh wording and be gentle
and assume that those who post something are no idiots.

What have broken binary drivers to do with a LSB standard?

Did Till write that the LSB standard applies only for
broken binary drivers?

For example the hpaio driver from HPLIP is free software.
For example the epkowa driver from IScan is free software.

I would appreciate it if there were more free drivers from
manufacturers but manufacturers ask for reliable standards.
If SANE1 was LSB, there would be such a reliable standard.

If SANE1 was LSB, it would not mean that there cannot be SANE2
but it would mean that a nice migration path from SANE1 to SANE2
would have to exist or that SANE2 is backward compatible to SANE1
(software for SANE1 would have to work in a SANE2 environment).


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex

[sane-devel] SANE2 standard completion

[Johannes Meixner]

Hello,

On Mar 28 18:40 Julien BLACHE wrote (shortened):
> ... 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

[sane-devel] SANE2 standard completion

[Étienne Bersac]

Hi,

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

[sane-devel] SANE2 standard completion

[Julien BLACHE]

"m. allan noah"  wrote:

Hi,

> 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    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Julien BLACHE]

?tienne Bersac  wrote:

Hi,

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

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

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

Yesh.

Wanna talk about your "INTEGRATE HAL IN SANE NOW OR ELSE..." approach?

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

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

>> 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" ?

>> 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    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Étienne Bersac]

Hi,

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

[sane-devel] SANE2 standard completion

[Étienne Bersac]

Hi,

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


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


> Everything is not a desktop, the desktop is only one use
> case.
?
Don't reduce desktop as window manager + xsane.


> And we DO care about it, thanks very much.

Sorry, what does mean DO ?


> Integrating WITH a desktop doesn't mean writing the whole stack FOR
> the desktop.

Where did you read such statment ???


> Now, please try to understand that.

Please try to understand end-users.


?tienne.
-- 
E Ultre?a !

[sane-devel] SANE2 standard completion

[Étienne Bersac]

Hi,

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

[sane-devel] SANE2, what do we want ?

[René Rebe]

Hi,

On 31.03.2008, at 13:15, ?tienne Bersac wrote:

> Hi,
>
> As a frontend developer, i just would like to
>
> * have SANE backend more consistent (more well known options
> including well known sensors)
> * compute SANE device name without loading the backend for  
> hotpluggable device.


did you wanted to tell this just to me, or missed to CC the sane-devel  
list?

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

[sane-devel] SANE2 standard completion

[m. allan noah]

On 3/31/08, ?tienne Bersac  wrote:
> Hi,
>
>
>  > 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.
>
>
>
>  > 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"

[sane-devel] SANE2 standard completion

[Emmanuel Fust]

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


 Cr?ez votre adresse ?lectronique pr?nom.nom at laposte.net 
 1 Go d'espace de stockage, anti-spam et anti-virus int?gr?s.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080330/a990045c/attachment.htm
 

[sane-devel] SANE2 standard completion

[Emmanuel Fust]

> Message du 28/03/08 22:50
> De : "Julien BLACHE"
> "m. allan noah"  wrote:
>
> Hi,
>
> >> - 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?nom.nom at laposte.net 
 1 Go d'espace de stockage, anti-spam et anti-virus int?gr?s.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080330/4a089f42/attachment.htm
 

[sane-devel] SANE2 standard completion

[m. allan noah]

On 3/30/08, Emmanuel Fust  wrote:
> > Message du 28/03/08 22:50
> > De : "Julien BLACHE"
> > "m. allan noah" wrote:
> >
> > Hi,
> >
> > >> - 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"

[sane-devel] SANE2, what do we want ?

[Rene Rebe]

On 28.03.2008, at 21:56, stef wrote:

>   Hello,
>
>   it seems that the real question is what do we want for SANE future ?
>
>   1 - the current situation is perfectly fine, don't need to change a  
> thing.
>
>   2 - only a couple of new image formats are needed, simply evolve a  
> few things.

+1

>   3 - put together the things we need to improve SANE, and have a new  
> standard.
>
>   4 - other proposition ...
>
>   I think that once there is an agreement on a common goal for SANE,  
> it will be easier to debate on how to achieve it.
>   
>   I'm rather inclined to the "3" goal, since I feel there are quite a  
> few things to do to improve SANE. Having a new standard doesn't mean  
> SANE 1 stops to exist. Both can coexist.


...

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

Till Kamppeter  wrote:

> ago and no one answered). This will help us that it is much easier for 
> scanner manufacturers to ship drivers with their scanners. They can 

This is all but a good thing. Currently, binary backends provided by
the manufacturers are nothing more than a total annoyance.

They're crappy, non-debuggable, under-documented, badly written, badly
tested, and available for Linux/i386 only.

Encouraging binary backends undermines the efforts done by backends
developers over the past years to obtain specification/documentation
from the manufacturers.

Think twice, please. You're actually actively harming both SANE and
the users by doing so.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

stef  wrote:

Hi,

Your mails are horribly formatted, please wrap your lines at 72
characters. Thanks!

>   indeed we are only a few people. But things can be done so
> that it isn't hard to achieve.
> However, does it mean you are akin to keep things as they are ? which
> is -of course- perfectly fine.

No, absolutely not. From my previous postings, I think it's obvious :)

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Till Kamppeter]

Note also one thing about the SANE2 discussion: Currently I am working 
on getting SANE1 into the LSB (I posted already about this some months 
ago and no one answered). This will help us that it is much easier for 
scanner manufacturers to ship drivers with their scanners. They can 
simply build them with the LSB DDK and then they will work on all 
(LSB-compliant) distros.

Till

stef wrote:
> Le Friday 28 March 2008 22:05:24 Julien BLACHE, vous avez ?crit :
>> stef  wrote:
>>
>> Hi,
>>
>>> I'm rather inclined to the "3" goal, since I feel there are
>>> quite a few things to do to improve SANE. Having a new standard
>>> doesn't mean SANE 1 stops to exist. Both can coexist.
>> Do you really think there is the needed manpower to co-maintain 2
>> versions of SANE?
>>
>> JB.
>>
>> -- 
>> Julien BLACHE    
>>   GPG KeyID 0xF5D65169
>>
> 
>   Hello,
> 
>   indeed we are only a few people. But things can be done so that it 
> isn't hard to achieve.
> However, does it mean you are akin to keep things as they are ? which is -of 
> course- perfectly fine.
> 
> Regards,
>   Stef
> 

[sane-devel] SANE2, what do we want ?

[stef]

Le Friday 28 March 2008 22:05:24 Julien BLACHE, vous avez ?crit?:
> stef  wrote:
> 
> Hi,
> 
> > I'm rather inclined to the "3" goal, since I feel there are
> > quite a few things to do to improve SANE. Having a new standard
> > doesn't mean SANE 1 stops to exist. Both can coexist.
> 
> Do you really think there is the needed manpower to co-maintain 2
> versions of SANE?
> 
> JB.
> 
> -- 
> Julien BLACHE    
>   GPG KeyID 0xF5D65169
> 

Hello,

indeed we are only a few people. But things can be done so that it 
isn't hard to achieve.
However, does it mean you are akin to keep things as they are ? which is -of 
course- perfectly fine.

Regards,
Stef

[sane-devel] SANE2, what do we want ?

[Julien BLACHE]

stef  wrote:

Hi,

>   I'm rather inclined to the "3" goal, since I feel there are
> quite a few things to do to improve SANE. Having a new standard
> doesn't mean SANE 1 stops to exist. Both can coexist.

Do you really think there is the needed manpower to co-maintain 2
versions of SANE?

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, what do we want ?

[Jon Chambers]

On Friday 28 March 2008, Julien BLACHE wrote:
> > I'm rather inclined to the "3" goal, since I feel there are
> > quite a few things to do to improve SANE. Having a new standard
> > doesn't mean SANE 1 stops to exist. Both can coexist.
> Do you really think there is the needed manpower to co-maintain 2
> versions of SANE?

To expand slightly on a previously made point: supposing a new 
(non-backward-compatible) standard were to be agreed upon then two 
glue/compatibility adaptors could be written:
1. connect SANE1 frontends to SANEX backends
2. connect SANEX-only frontends to SANE1 backends

This handles the cases of binary/abandoned front and back ends.  I suspect 
that hard bit will deciding all-new standard...

My 2p's worth...

cheers,
Jon

-- 
== Jon Chambers =
 http://www.jon.demon.co.uk, 020 8575 7097, 07931 961669
=

[sane-devel] SANE2, what do we want ?

[stef]

Hello,

it seems that the real question is what do we want for SANE future ?

1 - the current situation is perfectly fine, don't need to change a 
thing.

2 - only a couple of new image formats are needed, simply evolve a few 
things.

3 - put together the things we need to improve SANE, and have a new 
standard.

4 - other proposition ...

I think that once there is an agreement on a common goal for SANE, it 
will be easier to debate on how to achieve it.

I'm rather inclined to the "3" goal, since I feel there are quite a few 
things to do to improve SANE. Having a new standard doesn't mean SANE 1 stops 
to exist. Both can coexist.

Regards,
Stef

[sane-devel] SANE2 standard completion

[Julien BLACHE]

?tienne Bersac  wrote:

> 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    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Julien BLACHE]

Rene Rebe  wrote:

> The TWAIN standard is open, and here is the link:
>
>   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.

> Actually the capabilities are even quite similar.

That's what makes the most sense I think, so it's no surprise.

> 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    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Rene Rebe]

On 28.03.2008, at 19:34, m. allan noah wrote:

> On Fri, Mar 28, 2008 at 2:28 PM, Rene Rebe  wrote:
>>
>>
>> On 28.03.2008, at 19:19, m. allan noah wrote:
>>
>>
>>> On Fri, Mar 28, 2008 at 2:14 PM, Rene Rebe   
>>> wrote:
>>>

 On 28.03.2008, at 19:02, Alessandro Zummo wrote:


> On Fri, 28 Mar 2008 15:49:17 +0100
> Rene Rebe  wrote:
>
>
>>
>> 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?
>
> no- i mean no way to tell scanner that you want it to interlace  
> front and back.
>
>> 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

[sane-devel] SANE2 standard completion

[Étienne Bersac]

Hi,

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

[sane-devel] SANE2 standard completion

[Rene Rebe]

On 28.03.2008, at 19:19, m. allan noah wrote:

> On Fri, Mar 28, 2008 at 2:14 PM, Rene Rebe  wrote:
>>
>> On 28.03.2008, at 19:02, Alessandro Zummo wrote:
>>
>>> On Fri, 28 Mar 2008 15:49:17 +0100
>>> Rene Rebe  wrote:
>>>

 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

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 19:13, Julien BLACHE wrote:

> Rene Rebe  wrote:
>
> Hi,
>
>> 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

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 19:09, Julien BLACHE wrote:

> ?tienne Bersac  wrote:
>
> Hi,
>
>> Do you mean having some cups for scanner ?
>
> Something much more simple than CUPS, but yeah, basically.
>
>> 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.
>
>> 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.

+1 from me.

Yours,

-- 
   Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] SANE2 standard completion

[Rene Rebe]

On 28.03.2008, at 19:02, Alessandro Zummo wrote:

> On Fri, 28 Mar 2008 15:49:17 +0100
> Rene Rebe  wrote:
>
>>
>> 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

[sane-devel] SANE2 standard completion

[Julien BLACHE]

Rene Rebe  wrote:

Hi,

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

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Julien BLACHE]

?tienne Bersac  wrote:

Hi,

> Do you mean having some cups for scanner ?

Something much more simple than CUPS, but yeah, basically.

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

> 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    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

[Alessandro Zummo]

On Fri, 28 Mar 2008 15:49:17 +0100
Rene Rebe  wrote:

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

[sane-devel] SANE2 standard completion

[Étienne Bersac]

Hi,

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

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 18:40, Julien BLACHE wrote:

> "m. allan noah"  wrote:
>
> Hi,
>
>>>- 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

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 18:40, Oliver Rauch wrote:

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

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

> Best regards
> Oliver
>
> Am Freitag, den 28.03.2008, 08:52 +0100 schrieb 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.
>>
>> On 27.03.2008, at 18:22, stef wrote:
>>
>>> 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 param

[sane-devel] SANE2 standard completion

[Julien BLACHE]

"m. allan noah"  wrote:

Hi,

>> - 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    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2 standard completion

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

This is called progress. Really good.


Best regards
Oliver

Am Freitag, den 28.03.2008, 08:52 +0100 schrieb 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.
> 
> On 27.03.2008, at 18:22, stef wrote:
> 
> > 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
> > 
> > 
> >
> > -- 
> > sane-devel mailing list: sane-devel at lis

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi Allan,

On 28.03.2008, at 14:46, m. allan noah wrote:

> On Thu, Mar 27, 2008 at 1:22 PM, stef  wrote:
>>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.

>>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
.
>>- scanner's button handling
>
> this is overly complicated, and should be re-examined.
>
> [snip]

Ack.

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

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


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

[sane-devel] SANE2 standard completion

[m. allan noah]

On 3/28/08, Julien BLACHE  wrote:
> ?tienne Bersac  wrote:
>
>
> > 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"

[sane-devel] SANE2 standard completion

[m. allan noah]

On Fri, Mar 28, 2008 at 2:28 PM, Rene Rebe  wrote:
>
>
>  On 28.03.2008, at 19:19, m. allan noah wrote:
>
>
> > On Fri, Mar 28, 2008 at 2:14 PM, Rene Rebe  wrote:
> >
> > >
> > > On 28.03.2008, at 19:02, Alessandro Zummo wrote:
> > >
> > >
> > > > On Fri, 28 Mar 2008 15:49:17 +0100
> > > > Rene Rebe  wrote:
> > > >
> > > >
> > > > >
> > > > > 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?

no- i mean no way to tell scanner that you want it to interlace front and back.

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

[sane-devel] SANE2 standard completion

[m. allan noah]

On Fri, Mar 28, 2008 at 2:14 PM, Rene Rebe  wrote:
>
>  On 28.03.2008, at 19:02, Alessandro Zummo wrote:
>
>  > On Fri, 28 Mar 2008 15:49:17 +0100
>  > Rene Rebe  wrote:
>  >
>  >>
>  >> 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"

[sane-devel] SANE2 standard completion

[m. allan noah]

On Thu, Mar 27, 2008 at 1:22 PM, stef  wrote:
> 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.

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

> 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

general idea sounds good.

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

>
>  options changes:
> - capability hidden and allways settable added
> - more commonly used options are now part of the standard

general idea sounds good.

>
>  SANE operations changes:
> - sane_open has a SANE_Device ** parameter

sounds good.

> - scanner's button handling

this is overly complicated, and should be re-examined.

[snip]

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

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,


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

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

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

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

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

[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi,

On 28.03.2008, at 09:16, Alessandro Zummo wrote:

> On Fri, 28 Mar 2008 08:52:51 +0100
> Rene Rebe  wrote:
>
>> 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

[sane-devel] SANE2 standard completion

[Alessandro Zummo]

On Fri, 28 Mar 2008 08:52:51 +0100
Rene Rebe  wrote:

> 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

[sane-devel] SANE2 standard completion

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

On 27.03.2008, at 18:22, stef wrote:

>   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
>   
>   
>
> -- 
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>to sane-devel-request at lists.alioth.debian.org

-- 
  Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] SANE2 standard completion

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

[sane-devel] SANE2, time for a decision

[Johannes Meixner]

Hello,

David, David, Markus, Jens, George
I hope you don't mind that I included you in this thread
which is about a new/enhanced standard to access scanners.
At least I would like to have you informed, see the
"SANE2, time for a decision" thread on
http://lists.alioth.debian.org/pipermail/sane-devel/2007-January/thread.html
For basic information about SANE see
http://www.sane-project.org/intro.html
and for SANE2 see
http://www.sane-project.org/sane2/


On Jan 8 21:49 Jon Chambers wrote (shortened):
> Quite a few manufacturers have written proprietary backends
> and therefore have considered and silently endorsed the
> original SANE spec (for example Dell released a SANE driver
> for the 1815dn MFP).  Maybe they would provide some input
> if we asked them.  Does anyone have any friends amongst the 
> manufacturers that might be emailed?

If a new (or enhanced) standard is to be set up, I recommend
to ask the scanner manufacturers.

>From my communication with various manufacturers (mostly
regarding printing) I know that one gets always friendly
responses and after a few to and fro mails you know if a
manufacturer is really interested or not.

Then I recommend to simply ignore those who are not interested
because only friendly mails without any real progress will only
waste time.

But on the other hand those manufacturers who are interested
are very valuable and very helpful to get a wider range of vision
about the whole stuff, for example:
- How to deal with proprietary stuff?
  E.g. because of third-party license problems even a manufacturer
  may not be able to provide a driver which is completely free.
- How to deal with the scanners in big and fat all-in-one
  printer-scanner-copiers with only direct network access?
  Usually there is no SANE driver needed because those devices
  can produce an image file (e.g. PDF) and send it via email
  but how can such a device be used via a usual scanner frontend?

Obviously this may result further delays until the new standard
is ready to use (which does not mean it must be 100% ready)
but hopefully it makes sure that the new standard will not fail
or may not be accepted by third-parties which would then
make each their own weird obscure incompatible stuff.

I think it would be better to accept some more delay and then
get a really good new standard than an imperfect new standard.

Now some mail contacts which I hope to be useful:

Note that those may be not the exact right person to discuss
scanner specific stuff but they are at least a good point
to start because they know how free software works.

Epson / Epson Avasys:
Olaf Meeuwissen 
Already well known on this list ;-)

HP:
Suffield David 
In particular regarding HPLIP http://hplip.sourceforge.net/
the free software for HP printers and HP all-in-one devices
(but not for HP stand-alone scanners).

Kyocera / Kyocera Mita:
David Chamberlin 
Markus Brauer 

Sharp:
Stark Jens 

Ricoh family (Ricoh, Gestetner, Infotec, Lanier, NRG, Savin):
George Liu 

As far as I know Kyocera, Sharp, and Ricoh family do not provide
small stand-alone desktop scanners but big and fat all-in-one
printer-scanner-copiers (usually with direct network access).


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5  Mail: jsm...@suse.de
90409 Nuernberg, GermanyWWW: http://www.suse.de/

[sane-devel] SANE2, time for a decision

[Jon Chambers]

On Monday 08 January 2007 19:28, Gerhard Jaeger wrote:
> I also think we should setup a more or less small
> group of developers who are willing to help Oliver
> to finish the sane2 standard. [...]
> During this time the team around Oliver should
> be found and they could start with their work.

Alessandro summoned up some developer support for porting some backends.  I 
suspect that the number of people with sufficient spare time to devote to 
additionally reading, fully understanding and helping to finish the spec 
might be sufficiently small to allow some consensus to be reached before 
passing the result back out for general developer review.  Any volunteers?

> Apart from all of these standard discussions, our major
> problem is and probably will remain, that none of the
> scanner manufacturers supports us/SANE actively.

Quite a few manufacturers have written proprietary backends and therefore have 
considered and silently endorsed the original SANE spec (for example Dell 
released a SANE driver for the 1815dn MFP).  Maybe they would provide some 
input if we asked them.  Does anyone have any friends amongst the 
manufacturers that might be emailed?

cheers,
Jon


-- 
== Jon Chambers =
 http://www.jon.demon.co.uk, 020 8575 7097, 07931 961669
=

[sane-devel] SANE2, time for a decision

[Ariel Garcia]

Hi everybody,

> I also think we should setup a more or less small
> group of developers who are willing to help Oliver
> to finish the sane2 standard. We might should setup
> a list of stuff that should also go into this new
> standard - this list should be more or less a whishlist,
> which means that some points may find their way into
> the standard, some not.
> Let's keep this list open for lets say 4 weeks.
> During this time the team around Oliver should
> be found and they could start with their work.

reading this sane2 thread and seeing that some people have some quite 
different views of how to proceed regarding openness of the discussion,
i wanted to suggest to use a WIKI page for holding some kind of wishlist as 
Gerhard suggested, and another page for editing the document defining the 
standard. This last one could be read only for everybody except for a 
few 'editors'.
In this way even if the 'core' of the technical discussion and commits goes 
among just a few people, everybody can 'monitor' the results and speak out 
if they come with a brilliant or revolutionary idea ;-)


It is not necessary to have a finished ('written on stone') standard to 
start coding, but it is also not wise to start coding (call it fork sane-1 
or start from scratch, doesn't matter) without having a general idea of 
how the API should look like... 

My 2 cents...

Best wishes, Ariel

[sane-devel] SANE2, time for a decision

[Gerhard Jaeger]

On Sunday 07 January 2007 20:04, Martin Owens wrote:
> Toy might want to look at Enlightened Absolutism; because democracy
> doesn't work for software development. to inefficient.

full ack.

[SNIPSNAP]

I also think we should setup a more or less small
group of developers who are willing to help Oliver
to finish the sane2 standard. We might should setup
a list of stuff that should also go into this new
standard - this list should be more or less a whishlist,
which means that some points may find their way into
the standard, some not. 
Let's keep this list open for lets say 4 weeks.
During this time the team around Oliver should
be found and they could start with their work.

I'd like to see different people with different
focus within that team...

The resulting standard then should be opened for
some kind of discussion - but this time on the
SANE-Standard list.

Regarding SANE1, I think there's enough room for
extensions currently...

Apart from all of these standard discussions, our major
problem is and probably will remain, that none of the
scanner manufacturers supports us/SANE actively.

My two cents
Gerhard

BTW: Oliver, I'm also willing to help you out.

[sane-devel] SANE2, time for a decision

[Martin Owens]

Toy might want to look at Enlightened Absolutism; because democracy
doesn't work for software development. to inefficient.

If you want to develop a standard, do so; don't search for consensus
you only have to put it in public eyes for scrutiny, this doesn't stop
the development of driven people.

If it's required to fork to get the job done then do so. there is no
oligarchy here where a set of 'enlightened' developers are better than
everyone else because they've been doing it longer and are more
involved with sane so that some how affords them more rights (which it
doesn't) and ego and arrogance have no place in software development
either.

It's nice to think your in a special little club and that people can
either be under you or not involved but they don't work like that and
it's about time sane got it's act together and stop pissing in the
wind.

To conclude: Do what you have to, ignore the ego and the egocentrics.

Kind Regards, Martin Owens

On 07/01/07, Skorous  wrote:
> I think he meant that a small group of invested and motivated people
> would be able to make a lot faster progress rather than having to put
> every idea to a vote rather than saying that most people aren't
> qualified to participate. A republic vs. a democracy vs. benevolent
> dictatorship if you will ;-)
>
> On 1/6/07, m. allan noah  wrote:
> > On Sat, 6 Jan 2007, Oliver Rauch wrote:
> >
> > [snip]
> >
> > > The SANE2 standard is not finished, so it does not make sens to start 
> > > coding
> > > SANE2. It would be a big mistake to start coding SANE2 at this point 
> > > because
> > > the standard is not finished and will change.
> >
> > [snip]
> >
> > > I spent a lot of time in the SANE2 standard proposal. It took me a lot of
> > > energie and time to work out this proposal, but the following infinite and
> > > partly useless discussion about SANE2 (some years ago) made me stop my 
> > > work
> > > on it.
> >
> > your insistence on having a completed standard prior to coding is exactly
> > what created your desire to stop. you gave those who disagreed with you
> > the power to halt your development. i was not involved with sane 5 years
> > ago when most of the discussions took place, but i daresay that if i had
> > arrived on the scene and found that you personally had already started
> > coding sane2 with modest consensus and a history of being flexible, i
> > would have helped you.
> >
> > instead, we find ourselves staring at a standard that is outdated
> > regarding many of the new ideas that have come along in the last 4 years,
> > and any time someone tries to start up a discussion, they get told to hold
> > their horses cause the standard is not done?
> >
> > in the absense of a strong leader to direct things (no torvalds here), i
> > am willing to bet that we need some running code BEFORE the rough
> > consensus :)
> >
> > > The standard is not ready for coding, but we can finish it shortly, the 
> > > major
> > > part is done. But it is only possible when we create a little group (3-5
> > > backend and frontend programmers) that discuss and improve the standard
> > > proposal NON PUBLIC - or we will get the infinite discussion again.
> >
> > that is the most insulting suggestion that i have heard lately. only some
> > people on this list are qualified for the continuing discussion of sane2?
> > that the public only gets 1-2 weeks to comment?
> >
> > i am not nearly as good a programmer as you guys, but even i can see some
> > need for changes to the standard draft. the fact that prior discussions
> > got 'heated' (i dont know, i have not read them all) does not mean they
> > will again. that is, as long as the folks who put time into the current
> > draft are not afraid to see it change...
> >
> > 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-devel@lists.alioth.debian.org
> > http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> > Unsubscribe: Send mail with subject "unsubscribe your_password"
> >  to sane-devel-requ...@lists.alioth.debian.org
> >
>
> --
> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>  to sane-devel-requ...@lists.alioth.debian.org
>

[sane-devel] SANE2, time for a decision

[Skorous]

I think he meant that a small group of invested and motivated people
would be able to make a lot faster progress rather than having to put
every idea to a vote rather than saying that most people aren't
qualified to participate. A republic vs. a democracy vs. benevolent
dictatorship if you will ;-)

On 1/6/07, m. allan noah  wrote:
> On Sat, 6 Jan 2007, Oliver Rauch wrote:
>
> [snip]
>
> > The SANE2 standard is not finished, so it does not make sens to start coding
> > SANE2. It would be a big mistake to start coding SANE2 at this point because
> > the standard is not finished and will change.
>
> [snip]
>
> > I spent a lot of time in the SANE2 standard proposal. It took me a lot of
> > energie and time to work out this proposal, but the following infinite and
> > partly useless discussion about SANE2 (some years ago) made me stop my work
> > on it.
>
> your insistence on having a completed standard prior to coding is exactly
> what created your desire to stop. you gave those who disagreed with you
> the power to halt your development. i was not involved with sane 5 years
> ago when most of the discussions took place, but i daresay that if i had
> arrived on the scene and found that you personally had already started
> coding sane2 with modest consensus and a history of being flexible, i
> would have helped you.
>
> instead, we find ourselves staring at a standard that is outdated
> regarding many of the new ideas that have come along in the last 4 years,
> and any time someone tries to start up a discussion, they get told to hold
> their horses cause the standard is not done?
>
> in the absense of a strong leader to direct things (no torvalds here), i
> am willing to bet that we need some running code BEFORE the rough
> consensus :)
>
> > The standard is not ready for coding, but we can finish it shortly, the 
> > major
> > part is done. But it is only possible when we create a little group (3-5
> > backend and frontend programmers) that discuss and improve the standard
> > proposal NON PUBLIC - or we will get the infinite discussion again.
>
> that is the most insulting suggestion that i have heard lately. only some
> people on this list are qualified for the continuing discussion of sane2?
> that the public only gets 1-2 weeks to comment?
>
> i am not nearly as good a programmer as you guys, but even i can see some
> need for changes to the standard draft. the fact that prior discussions
> got 'heated' (i dont know, i have not read them all) does not mean they
> will again. that is, as long as the folks who put time into the current
> draft are not afraid to see it change...
>
> 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-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>  to sane-devel-requ...@lists.alioth.debian.org
>

[sane-devel] SANE2, time for a decision

[m. allan noah]

On Sat, 6 Jan 2007, Oliver Rauch wrote:

[snip]

> The SANE2 standard is not finished, so it does not make sens to start coding
> SANE2. It would be a big mistake to start coding SANE2 at this point because
> the standard is not finished and will change.

[snip]

> I spent a lot of time in the SANE2 standard proposal. It took me a lot of
> energie and time to work out this proposal, but the following infinite and
> partly useless discussion about SANE2 (some years ago) made me stop my work
> on it.

your insistence on having a completed standard prior to coding is exactly 
what created your desire to stop. you gave those who disagreed with you 
the power to halt your development. i was not involved with sane 5 years 
ago when most of the discussions took place, but i daresay that if i had 
arrived on the scene and found that you personally had already started 
coding sane2 with modest consensus and a history of being flexible, i 
would have helped you.

instead, we find ourselves staring at a standard that is outdated 
regarding many of the new ideas that have come along in the last 4 years, 
and any time someone tries to start up a discussion, they get told to hold 
their horses cause the standard is not done?

in the absense of a strong leader to direct things (no torvalds here), i 
am willing to bet that we need some running code BEFORE the rough 
consensus :)

> The standard is not ready for coding, but we can finish it shortly, the major
> part is done. But it is only possible when we create a little group (3-5
> backend and frontend programmers) that discuss and improve the standard
> proposal NON PUBLIC - or we will get the infinite discussion again.

that is the most insulting suggestion that i have heard lately. only some 
people on this list are qualified for the continuing discussion of sane2? 
that the public only gets 1-2 weeks to comment?

i am not nearly as good a programmer as you guys, but even i can see some 
need for changes to the standard draft. the fact that prior discussions 
got 'heated' (i dont know, i have not read them all) does not mean they 
will again. that is, as long as the folks who put time into the current 
draft are not afraid to see it change...

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] SANE2, time for a decision

[Alessandro Zummo]

On Sat, 06 Jan 2007 23:31:03 +0100
Julien BLACHE  wrote:

> Alessandro Zummo  wrote:
> 
> >  A fork will inevitably lead to more features
> >  and that might as well turn into sane2.
> 
> Or to an utter failure.
> 
> You need to calm down and think this through.
> 
> Henning told you that already, Oliver just told you that too. Are you
> going to start listening, or continue banging your head against the
> wall ?

 Julien, the problem is that sane2 hasn't happened in the last years
 and if things are not going to change it will not happen.

 The first draft I can see is dated in mid 2002. We are in 2007 now.

 Something must change and I see no signs that is is going to happen.
 I don't have any particular need for sane2 but nonetheless I'm trying
 to gather support for it. I'm trying to do things in a different way
 than before, to see if this can lead somewhere.

 Thinking and planning is surely important but code needs
 to be written from time to time.

 SANE2 is not so different that a forked SANE1 cannot evolve into.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] SANE2, time for a decision

[Julien BLACHE]

Alessandro Zummo  wrote:

>  A fork will inevitably lead to more features
>  and that might as well turn into sane2.

Or to an utter failure.

You need to calm down and think this through.

Henning told you that already, Oliver just told you that too. Are you
going to start listening, or continue banging your head against the
wall ?

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] SANE2, time for a decision

[Oliver Rauch]

Am Samstag, 6. Januar 2007 20:39 schrieben Sie:

> > This way we could have finished the standard in about 8-12 weeks.
> >
> > After that we could start coding SANE2. And when this standard is worth
> > to support it then there will be coders for sanei-code and for frontends.
>
>  I do agree on the timeframe, but don't think we can find devs this way.
>  The people who were interested has already posted in this list,
>  I don't think there are more left.

1) We do not need to convert all backends from SANE1 to SANE2,
a SANE2 frontend can and should support SANE1 and SANE2 backends.

2) we have some developers that publicy told that they will support
some sane-backends for SANE2. There will be a lot more that will
work on it when the work has begun. There will be several developers who will 
support SANE2 but they don?t want to promise it in the moment and so they 
don`t shout out loud that they will work on it. But there are lot that will 
work on SANE2 - I am sure.

The most important thing is to get a SANE2 test backend and a SANE2
compatible frontend, otherwise noone will be able to use a SANE2 backend.

I will make xsane SANE2 compatible - may be not with the highest priority, so 
it will take some time, but I will work on it - when the SANE2 standard is 
worth to be supported.

I am sure there will be several developpers that convert scanimage and 
xscanimage, and we will see how soon quiteinsane, kooka etc. will be made 
SANE2 compatible.

What we need is a consensus that we have a SANE2 standard that all (or most of 
the) active developers can accept.

But I also can say that I will not support the SANE2 standard when we get the 
same infinite sensless and aggressive discussion we had some years ago.


Best regards
Oliver

[sane-devel] SANE2, time for a decision

[Alessandro Zummo]

On Sat, 06 Jan 2007 17:09:08 +0100
Frank Zago  wrote:

> >  The poll options will be:
> >
> >  - Reopen development on SANE1
> >  - Fork SANE1
> >  - Wait SANE2 indefinitely
> >   
> Or "evolve a fork of SANE1 into SANE2".

 A fork will inevitably lead to more features
 and that might as well turn into sane2.

> >  I will gladly accept suggestions for other options
> >  as long as they are credible. i.e. "Develop SANE2"
> >  will not be accepted unless it includes a list of
> >  developers that are going to make it happen.
> >
> >  I'm sorry for being a bit rough, but time is
> >  passing by and we need to go somewhere.
> >
   
> All it takes is a motivated person.
> I can provide a some of my time to help, but I cannot commit to much.

 Even a small amount is appreciated ;) I'd be happy to see an improvement
 in the build system.. you maybe can help on that.
 
> I have found an e-mail I wrote a few years back, which remains so true
> to me:
> http://lists.alioth.debian.org/pipermail/sane-devel/2003-August/008482.html


 so true.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] SANE2, time for a decision

[Alessandro Zummo]

On Sat, 6 Jan 2007 17:15:03 +0100 (MET)
Oliver Rauch  wrote:

> 
> The SANE2 standard is not finished, so it does not make sens to start coding 
> SANE2. It would be a big mistake to start coding SANE2 at this point because 
> the standard is not finished and will change.
> 
> What should be done is:
> 
> - continue SANE1 development and finish the SANE2-standard soon.

 imho we don't have devs to do both things at the same time.

> The standard is not ready for coding, but we can finish it shortly, the major 
> part is done. But it is only possible when we create a little group (3-5 
> backend and frontend programmers) that discuss and improve the standard 
> proposal NON PUBLIC - or we will get the infinite discussion again.

 [..]
> 
> This way we could have finished the standard in about 8-12 weeks.
> 
> After that we could start coding SANE2. And when this standard is worth to 
> support it then there will be coders for sanei-code and for frontends.

 I do agree on the timeframe, but don't think we can find devs this way. 
 The people who were interested has already posted in this list,
 I don't think there are more left.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] SANE2, time for a decision

[Frank Zago]

Hello Alessandro Zummo,
>  Hello sane developers,
>
>   Some weeks ago I introduced (once again) the discussion
>  about SANE future. Now is time to take action.
>
>   The situation is that we have coders willing to implement
>  the SANE2 standard (whatever this will be) for a bunch of backends
>  but are missing the people required to revamp sanei, the build
>  system and the frontends.
>
>   The standard itself is not complete, but this is something
>  that can be fixed.
>
>   However, we already have lost too much time in this limbo.
>   
Not even a decade :)

>  I would like to run a poll (suggestions for good poll web sites
>  are accepted) asking user and devs what they think about the
>  SANE future.
>
>  The poll options will be:
>
>  - Reopen development on SANE1
>  - Fork SANE1
>  - Wait SANE2 indefinitely
>   
Or "evolve a fork of SANE1 into SANE2".
>  I will gladly accept suggestions for other options
>  as long as they are credible. i.e. "Develop SANE2"
>  will not be accepted unless it includes a list of
>  developers that are going to make it happen.
>
>  I'm sorry for being a bit rough, but time is
>  passing by and we need to go somewhere.
>   
All it takes is a motivated person.
I can provide a some of my time to help, but I cannot commit to much.

I have found an e-mail I wrote a few years back, which remains so true
to me:
http://lists.alioth.debian.org/pipermail/sane-devel/2003-August/008482.html

Frank.

[sane-devel] SANE2, time for a decision

[Oliver Rauch]

Am Samstag, 6. Januar 2007 16:19 schrieb Alessandro Zummo:

>  The poll options will be:
>
>  - Reopen development on SANE1
>  - Fork SANE1
>  - Wait SANE2 indefinitely


The SANE2 standard is not finished, so it does not make sens to start coding 
SANE2. It would be a big mistake to start coding SANE2 at this point because 
the standard is not finished and will change.

What should be done is:

- continue SANE1 development and finish the SANE2-standard soon.

I spent a lot of time in the SANE2 standard proposal. It took me a lot of 
energie and time to work out this proposal, but the following infinite and 
partly useless discussion about SANE2 (some years ago) made me stop my work 
on it.

The standard is not ready for coding, but we can finish it shortly, the major 
part is done. But it is only possible when we create a little group (3-5 
backend and frontend programmers) that discuss and improve the standard 
proposal NON PUBLIC - or we will get the infinite discussion again.

The non-public discussion should take some (4-8) weeks and then the group 
should publish their improved SANE2-standard proposal.

After that we can make a little discussion (1-2 weeks) about the improved 
proposal and give the group some time (1-2 weeks) to improve the proposal 
again based on the comments and suggestion.

This way we could have finished the standard in about 8-12 weeks.

After that we could start coding SANE2. And when this standard is worth to 
support it then there will be coders for sanei-code and for frontends.

Best regards
Oliver


 

[sane-devel] SANE2, time for a decision

[Alessandro Zummo]

 Hello sane developers,

  Some weeks ago I introduced (once again) the discussion
 about SANE future. Now is time to take action.

  The situation is that we have coders willing to implement
 the SANE2 standard (whatever this will be) for a bunch of backends
 but are missing the people required to revamp sanei, the build
 system and the frontends.

  The standard itself is not complete, but this is something
 that can be fixed.

  However, we already have lost too much time in this limbo.

 I would like to run a poll (suggestions for good poll web sites
 are accepted) asking user and devs what they think about the
 SANE future.

 The poll options will be:

 - Reopen development on SANE1
 - Fork SANE1
 - Wait SANE2 indefinitely

 I will gladly accept suggestions for other options
 as long as they are credible. i.e. "Develop SANE2"
 will not be accepted unless it includes a list of
 developers that are going to make it happen.

 I'm sorry for being a bit rough, but time is
 passing by and we need to go somewhere.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] SANE2 commitment

[abel deuring]

Alessandro Zummo wrote:
> 
>  Hello developers,
> 
>since there seems to be interest in developing sane2, I've decided
>  to start this thread in order to collect the commitment of each developer.
> 
>  I'm willing to port the epson driver to sane2, help porting the
>  coolscan driver and handle the command line frontend. 
> 
>  I think Giuseppe Sacco has showed interest to do coolscan
>  bits. 
> 
>  A friend of mine, Stefano Merlo, has committed himself
>  to the canon driver.
> 
>  I'd appreciate if everyone who is interested can reply
>  with their own commitments for the 2007.. ehm.. sane2 :)

Firstly, kudos to Alessandro for starting a new attempt to get Sane2
going.

Let's make sure that we don't get again an ugly exchange of
arguments like we had, ummm, seven (?) years ago, which eventually
"froze" the first attempt of a new version of Sane.

Unfortunately, I can't make at present an honest commitment for
contributions to Sane2 in the next year -- it is quite unclear how
much time I will have.

If I find time, I will work on the Sharp backend, on the sanei_scsi
library (well, mostly it's Linux part... I don't know enough about
the other platforms supported by Sane) and a Python library for Sane.

I agree with Martin and Etienne that device detection and desktop
integration should be improved, but I also think that we should keep
support for operating systems that don't have any HAL support. My
problem is that I don't know anything about HAL implementation in
Linux or elsewhere -- can anybody give me a pointer to an introduction?

Abel

[sane-devel] SANE2 commitment

[Étienne Bersac]

hi all,

I'm working on Gnome Scan and intend to be very active in this realm in
the next year.

This may hurt some people here.

I want to bring scan support to hal. I intended to talk with sane people
in january. I want in Gnome to use sane for access, not probe/detection.

That's bad to probe each time you launch the app. I wonder if we need a
kind of cups for scanner that use sane to access, receive job request
and return stream of pictures. I wonder how to handle local and
networked detection. I want to add avahi feature to scanner share.

Likely, SANE 2 offer a new sane_open () prototype that allow to get
device description without doing the probe. But how can hal know the
sane device name ? I would like to add a "scanner.sane.name" field or
similar into hal scanner device in order to allow app to use directly
SANE (basically, a scaner cups will do that). Is this possible with SANE
1 ? If not, how does SANE 2 help for that ?

Some of you may be attached to the double work of sane : device support,
device probe. But i really think SANE must add a way for developer to
handle device detection according to the target system standard (e.g.
hal, windows, Solaris, etc.).

I do not want sane to drop sane_get_devices (). Would be nice to get
sane device name from vid/pid or some other info an OS/hal can give.
That's easy to implement a simple hal addon that handle the filling of
scanner.sane.name field.

I wish you will understand that need.

Kind regards,
?tienne.
-- 
Verso l'Alto !
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20061217/d5528193/attachment.pgp
From bersac...@laposte.net  Sun Dec 17 22:36:23 2006
From: bersac...@laposte.net (=?ISO-8859-1?Q?=C9tienne?= Bersac)
Date: Tue Dec 19 19:42:50 2006
Subject: [sane-devel] SANE2 commitment
In-Reply-To: <69ff73b20612171152h1110e1deleb7b80d30264...@mail.gmail.com>
References: <20061215175700.4c974c89@inspiron>
<45854deb.9010...@penguin-breeder.org>
<20061217172351.70067897@inspiron>
<45858d8f.6080...@zago.net> <20061217201545.2a7c85c3@inspiron>
<4585998d.7030...@zago.net> <20061217203458.10327e0e@inspiron>
<69ff73b20612171152h1110e1deleb7b80d30264...@mail.gmail.com>
Message-ID: <1166391382.5549.17.camel@thilivren>

Skipped content of type multipart/mixed-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20061217/a9772311/attachment.pgp
From bersac...@laposte.net  Tue Dec 19 15:55:10 2006
From: bersac...@laposte.net (=?ISO-8859-1?Q?=C9tienne?= Bersac)
Date: Tue Dec 19 20:19:59 2006
Subject: [sane-devel] SANE2 commitment
In-Reply-To: <1166539654.30598.31.camel@casa>
References: <20061215175700.4c974c89@inspiron>
<45854deb.9010...@penguin-breeder.org>
<20061217172351.70067897@inspiron>
<45858d8f.6080...@zago.net> <20061217201545.2a7c85c3@inspiron>
<4585998d.7030...@zago.net> <20061217203458.10327e0e@inspiron>
<69ff73b20612171152h1110e1deleb7b80d30264...@mail.gmail.com>
<1166539654.30598.31.camel@casa>
Message-ID: <1166540109.5681.35.camel@thilivren>

Hi,

> That would be really nice. I wonder if this will only work on linux.
> What about *BSD, Solaris and Windows?

I think that SANE must implement a modular OS <-> SANE API that allow OS
to ask SANE to load a driver for one device and the monitor buttons, ?
SANE should then also implement a "legacy" probe mecanism for other OSes
or other purpose (distro not shiping HAL, etc.).

?tienne.
-- 
Verso l'Alto !
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20061219/36fc8090/attachment.pgp
From bersac...@laposte.net  Tue Dec 19 20:57:38 2006
From: bersac...@laposte.net (=?ISO-8859-1?Q?=C9tienne?= Bersac)
Date: Tue Dec 19 22:58:39 2006
Subject: [sane-devel] Frontends : Gnome Scan 0.4 !
Message-ID: <1166558258.5681.99.camel@thilivren>

Hi all !

Gnome Scan 0.4 has been released with nice gui improvments and new
features like x/y resolutions, computed area & rotation, ?

http://gnome-scan.blogspot.com/2006/12/releasing-04-is-your-app

[sane-devel] SANE2 commitment

[Martin Owens]

> >
> > You can then change your clients to use hal and simply call dbus
> > commands to scan etc.
> [...]
>
> That would be really nice. I wonder if this will only work on linux.
> What about *BSD, Solaris and Windows?

I don't know about solaris, I know hal is being used in a number of
linux distributions but not even all of them. windows has it's own hal
and less is known about it.

It might end up being a separate project for integrating sane with hal
in order to repackage sane for certain linux distributions that can
take advantage of newer device systems.

>
> Bye,
> Giuseppe

Best Regards, Martin

[sane-devel] SANE2 commitment

[Giuseppe Sacco]

Hi Martin,

Il giorno dom, 17/12/2006 alle 19.52 +, Martin Owens ha scritto:
[...]
> For device detection and management use HAL, update hal dbus code with
> all existing detection and status code which will keep these devices
> happy, enable the modification of the hal xml as a simple way of
> keeping track of which scanners work with which backends too, removing
> this from the backend code is a must.
> 
> You can then change your clients to use hal and simply call dbus
> commands to scan etc.
[...]

That would be really nice. I wonder if this will only work on linux.
What about *BSD, Solaris and Windows?

Bye,
Giuseppe