On Sun, 14 Jun 2009 21:29:27 +0200
stef wrote:
> You are right, I didn't understand what you meant.
> So for now, what is sure is that some changes are planned to the API,
> and
> there will be a bump in the soname version ?
From my point of view, I agree with stef regarding "wri
On Mon, 15 Jun 2009 20:55:23 +0200
Julien BLACHE wrote:
> > my vote is for the 4th option.
>
> And here I was, thinking you people wanted to see some progress made.
>
> You do realize that option 4 basically guarantees that pretty much
> nothing major will happen, will drag on for years and
Alessandro Zummo wrote:
Hi,
>> 4: make our API modifications small enough that old backends will be
>> forward compatible
>>
>> Note that all 4 of these options are easier for the programmer if the
>> API changes are kept small. Are there any other choices?
>
> my vote is for the 4th option.
On Fri, 12 Jun 2009 13:52:57 -0400
"m. allan noah" wrote:
> 4: make our API modifications small enough that old backends will be
> forward compatible
>
> Note that all 4 of these options are easier for the programmer if the
> API changes are kept small. Are there any other choices?
my vote is
On Fri, 12 Jun 2009 12:45:07 -0400
Richard Ryniker wrote:
> Certainly, there are places where indefinitely extensible interfaces have
> value. XML, ASN.1 are two examples that come immediately to mind. I
> believe SANE, like many other applications, will find it better to change
> its API in in
Le dimanche 14 juin 2009 21:10:29 m. allan noah, vous avez ?crit :
> >
> >but after a quick read, it seems to me that the draft doesn't
> > address user notification during warming up, nor the case of sheet fed
> > scanners calibration.
>
> I think you missed my point. I did not say th
Time to delurk myself for a bit.
On Sat, Jun 13, 2009 at 8:55 AM, m. allan noah wrote:
> We already tried that. It is called the sane 2 draft spec, and its
> been sitting on the server for years. IMHO, we should not start
> another round of open-ended dreaming. We must keep in mind what is
> possi
On Sat, Jun 13, 2009 at 3:40 PM, stef wrote:
> Le samedi 13 juin 2009 14:55:54 m. allan noah, vous avez ?crit :
>> On Sat, Jun 13, 2009 at 8:42 AM, stef wrote:
>> > Le vendredi 12 juin 2009 19:52:57 m. allan noah, vous avez ?crit :
>> >> On Fri, Jun 12, 2009 at 12:45 PM, Richard
>> >>
>> >> Ryniker
Le samedi 13 juin 2009 14:55:54 m. allan noah, vous avez ?crit :
> On Sat, Jun 13, 2009 at 8:42 AM, stef wrote:
> > Le vendredi 12 juin 2009 19:52:57 m. allan noah, vous avez ?crit :
> >> On Fri, Jun 12, 2009 at 12:45 PM, Richard
> >>
> >> Ryniker wrote:
> >> >> a frontend that asks for new, unsupp
Le vendredi 12 juin 2009 19:52:57 m. allan noah, vous avez ?crit :
> On Fri, Jun 12, 2009 at 12:45 PM, Richard
>
> Ryniker wrote:
> >> a frontend that asks for new, unsupported features, will simply
> >> get an appropriate error code.
> >
> > Allen Noah, earlier in this thread (Thu Jun 11 19:08:28
On Sat, Jun 13, 2009 at 8:42 AM, stef wrote:
> Le vendredi 12 juin 2009 19:52:57 m. allan noah, vous avez ?crit :
>> On Fri, Jun 12, 2009 at 12:45 PM, Richard
>>
>> Ryniker wrote:
>> >> a frontend that asks for new, unsupported features, will simply
>> >> get an appropriate error code.
>> >
>> > Al
On Friday 12 June 2009 20:52:57 m. allan noah wrote:
> On Fri, Jun 12, 2009 at 12:45 PM, Richard
>
> Ryniker wrote:
> >> a frontend that asks for new, unsupported features, will simply
> >> get an appropriate error code.
> >
> > Allen Noah, earlier in this thread (Thu Jun 11 19:08:28 UTC 2009) allu
"m. allan noah" wrote:
> Seriously, we have to bump the major number on the soversion to do any
> changes. The only real question is what do we do with all the
> unmaintained backends?
We leave them behind for now, and we'll see later what to do about
them. In the meantime, maintainers can pop u
On Fri, Jun 12, 2009 at 12:45 PM, Richard
Ryniker wrote:
>> a frontend that asks for new, unsupported features, will simply
>> get an appropriate error code.
>
> Allen Noah, earlier in this thread (Thu Jun 11 19:08:28 UTC 2009) alluded
> to the problem with this approach when he wrote:
>
>>bah- the
> a frontend that asks for new, unsupported features, will simply
> get an appropriate error code.
Allen Noah, earlier in this thread (Thu Jun 11 19:08:28 UTC 2009) alluded
to the problem with this approach when he wrote:
>bah- then no front-end will use it, since it is not guaranteed to be
>ther
On Fri, 12 Jun 2009 09:35:55 +0200
Julien BLACHE wrote:
> > What happens if the API gets extended somehow? You take
> > them all off the list again and iterate?
>
> Yes, it becomes a mess for everybody when that happens.
>
> And it doesn't make sense anyway. What do we ship as sane-backends
Alessandro Zummo wrote:
Hi,
>> Why do all 80 backends (as of 1.0.20) _have_ to be released together?
>> Why do all backends that are at the correct API revision _have_ to be
>> released together?
>
> What happens if the API gets extended somehow? You take
> them all off the list again and iter
On Fri, 12 Jun 2009 08:52:58 +0900
Olaf Meeuwissen wrote:
> Why do all 80 backends (as of 1.0.20) _have_ to be released together?
> Why do all backends that are at the correct API revision _have_ to be
> released together?
What happens if the API gets extended somehow? You take
them all off th
Julien BLACHE writes:
> "m. allan noah" wrote:
>
> [gah the mail was really for the list, sorry]
>
>> We can certainly open the API up for changes, but whoever wants to see
>> the change had better be prepared to go into every backend and add the
>> code...
That might be a bit problematic with
On Thu, 11 Jun 2009 15:08:28 -0400
"m. allan noah" wrote:
> >
> > ?a backend might choice to implement it or not. such an info is
> > ?useful but shouldn't be mandatory.
>
> bah- then no front-end will use it, since it is not guaranteed to be
> there. So, they will still cache the data from sa
"m. allan noah" wrote:
[gah the mail was really for the list, sorry]
> We can certainly open the API up for changes, but whoever wants to see
> the change had better be prepared to go into every backend and add the
> code...
Or we just take the sane (yeah, right, can we change our project's
nam
On Thu, 11 Jun 2009 14:54:32 -0400
"m. allan noah" wrote:
> > ?exactly ;) I hate having to cache the device.
>
> We can certainly open the API up for changes, but whoever wants to see
> the change had better be prepared to go into every backend and add the
> code...
a backend might choice to
On Thu, Jun 11, 2009 at 3:05 PM, Alessandro
Zummo wrote:
> On Thu, 11 Jun 2009 14:54:32 -0400
> "m. allan noah" wrote:
>
>> > ?exactly ;) I hate having to cache the device.
>>
>> We can certainly open the API up for changes, but whoever wants to see
>> the change had better be prepared to go into
On Wed, Jun 10, 2009 at 7:45 PM, Alessandro
Zummo wrote:
> On Thu, 11 Jun 2009 08:24:37 +0900
> Olaf Meeuwissen wrote:
>
>> ? ?nice! while we are there, I'd love to have a function to retrieve
>> > ?the scanner maker and model
>>
>> What's wrong with SANE_Device.vendor and SANE_Device.model?
>> #
Alessandro Zummo writes:
> On Wed, 10 Jun 2009 19:15:24 +0200
> Julien BLACHE wrote:
>
>> There are a couple of limitations that cannot be lifted without that,
>> so yes.
>
> nice! while we are there, I'd love to have a function to retrieve
> the scanner maker and model
What's wrong with SA
On Thu, 11 Jun 2009 08:24:37 +0900
Olaf Meeuwissen wrote:
>nice! while we are there, I'd love to have a function to retrieve
> > the scanner maker and model
>
> What's wrong with SANE_Device.vendor and SANE_Device.model?
> # Getting that SANE_Device is another matter ;-)
exactly ;) I h
On Wed, 10 Jun 2009 19:15:24 +0200
Julien BLACHE wrote:
> There are a couple of limitations that cannot be lifted without that,
> so yes.
nice! while we are there, I'd love to have a function to retrieve
the scanner maker and model
--
Best regards,
Alessandro Zummo,
Tower Technologie
Alessandro Zummo wrote:
Hi,
>> Whatever we do requires careful consideration to produce a better API
>> that will fix the current shortcomings without introducing new ones
>> that we can avoid. (like, say, busy-looping on sane_start(), shrug.)
>
> so the plan is whole new API not binary compati
On Wed, 10 Jun 2009 18:27:41 +0200
Julien BLACHE wrote:
> Whatever we do requires careful consideration to produce a better API
> that will fix the current shortcomings without introducing new ones
> that we can avoid. (like, say, busy-looping on sane_start(), shrug.)
so the plan is whole new A
stef wrote:
> This is why I regret that recent plans to bring a little evolution
> were
> postponed over such a mundane thing than a dll version. An frequent
I think you still haven't got it.
There are plans for changes to the API; Allan reviewed the SANE2 draft
but I believe he's bus
Hello,
Here's a little story that happened months ago: my wife wanted to scan
a
document with our MD6471 run by the genesys backend. She calls me:
- It isn't working !
- What is happening ? (as a backend maintainer I rushed, quite upset)
- It doesn't move.
31 matches
Mail list logo
