Sure. Once you have the source in SANE style, compiling for another platform
is simple. The problem with getting source will be, that many manufacturers
will be pretty reluctant to give it out.
While I personally doubt the commonly named reasons for this are really
valid, I have to accept that, as the source is the writer's intellectual
property, and he may decide what to do with it.
But as said: If compiling the source on any platform is very easy, it gets
more and more probable, that it will happen as well.
We could even set up "trusted hosts" to compile the drivers on
all known architectures automatically, when a manufacturer sends
them there.
> and should not be ignored. Alpha (64 bits) and sparc (which is the other
> endian if I remember right) present difficult problems if they are not
> solved inheirantly in the design.
Not really. Decently written software does not require much fuzzing around
with endianness and data sizes.
Note, that SANE seems to work well at least on Alpha, or David would
probably not maintain it ;-).
> > Yes. Adding an ASPI layer for SANE should IMHO be no big deal. Generic SCSI
> > support is there for the Unixes in some flavours, so I assume adding in
> > ASPI shouldn't be a big deal.
> Let me interrupt here and suggest Java. Not nessicatly the programing
> languge as Sun has defined it (though that has advantages), but something
> with a simielar goal: a simple API/Programing language that can be used
> to create a backend. This will run on all platforms (ideally without the
> endian issues that plague Sane today).
I actually do not think, that interpreted bytecode is the greatest thing
since sliced bread. O.K. - we are talking about scanners, that makes
speed less of an issue usually, but I really do not think, we should waste
lots of ressources interpreting bytecode, when all that is needed for
getting a platform supported is ./configure;make;.
I see your point about having instant support for every platform with that
method, but I do not think it is practical. Just think about the development
environments that would have to be written ....
> internet. Because the backend is platform independant there is no problem
> with the manufacture not wanting to tell you how their scanner works, like
> Sane faces today.
Not too right. We probably agree, that bytecode interpreted code would be
required to get that level of portability. Now inside a modularized system
like SANE, where drivers are relatively small and forced to communicate over
predefined channels, reverse engineering becomes magnitudes easier.
I have reverse engineered quite some software for various reasons, and the
point is: The smaller the individual module, the better defined the
interfaces and the higher level the development tools that were used in
creating the thing, the easier it is to reverse engineer.
> > Most other methods (homebrew interface cards and such) aren't in common use
> > anymore these days.
> Thank God... Twane should probably expliciatly state that other
> interfaces are not supported. I'd consider dropping parallel ports and
> serial ports in favor of Usb. (this probably isn't pratical yet, but a
> footnote to suggest moving to USB)
Note, that USB support in Unix is severly lacking.
> I don't think Sane provides a network neighborhood type scanner brwoser,
> but that would be a nice addition.
No, it doesn't. It would be possible, though. The simplest way would be
to autoprobe through the whole subnet. Other than that an announcement
scheme would have to be invented.
CU, ANdy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> =
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com