sane-project-website/old-archive/1999-02/0155.html

<!-- received="Tue Feb 23 13:53:47 1999 PST" -->
<!-- sent="Tue, 23 Feb 1999 17:03:44 -0500 (EST)" -->
<!-- name="Tripp Lilley" -->
<!-- email="tlilley@perspex.com" -->
<!-- subject="Some thoughts about the SANE API" -->
<!-- id="" -->
<!-- inreplyto="" -->
<title>sane-devel: Some thoughts about the SANE API</title>
<h1>Some thoughts about the SANE API</h1>
<b>Tripp Lilley</b> (<a href="mailto:tlilley@perspex.com"><i>tlilley@perspex.com</i></a>)<br>
<i>Tue, 23 Feb 1999 17:03:44 -0500 (EST)</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#155">[ date ]</a><a href="index.html#155">[ thread ]</a><a href="subject.html#155">[ subject ]</a><a href="author.html#155">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0156.html">Wolfgang Goeller: "Re: Acer scanners"</a>
<li> <b>Previous message:</b> <a href="0154.html">Darren Marshall: "Re: Primax for Linux - temp. down"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
As I've mentioned, I'm in the process of writing a Perl module to do SANE<br>
stuff. I noticed today (and have noticed before) a Perl module called<br>
Image::Grab, designed to retrieve images from URLs. I started thinking<br>
about it, and wondering if it would make more sense for such a thing to be<br>
a SANE backend. SANE, in a sense, provides a fairly generic raster image<br>
encapsulation, and a well-designed set of SANE backends, and a mechanism<br>
for helping a program decide which backend was the "best choice" given a<br>
user's input, would make a fairly complete and easy way for a program to<br>
support image acquisition across the board.<br>
<p>
Okay, so I repeat much of the original vision of TWAIN and SANE (SANE<br>
being, of course, far preferable to TWAIN because it's, well, sane).<br>
However, there are a couple of areas in which I believe a 1.5 or 2.0<br>
version of the SANE API needs "improvement" to become a more generic image<br>
acquisition service. These are not fully fleshed-out thoughts, but are<br>
random musings that occured to me in an unspecified location, dominated by<br>
a preponderance of porcelain and plumbing.<br>
<p>
* As mentioned in another thread, there needs to be support for image<br>
sources which do not, themselves, know when to quit. Hand scanners were<br>
the particular example, but any other sort of continuous-capture device<br>
would fit the model.<br>
<p>
* There ought to be a way to mark certain options as "having to be<br>
configured per-scan". In other words, options that a software package<br>
ought to prompt for, or otherwise set, each time the acquisition happens.<br>
For an "Image::Grab" backend, for instance, the URL from which to grab,<br>
and perhaps an image type, would make sense as things to be prompted for<br>
before each acquisition.<br>
<p>
Addressing the first point, it might make sense to define a generic<br>
"event" model that allows a driver to specify to which events it will<br>
respond during acquisition, and some simple semantics of its response. For<br>
instance, a hand-scanner backend might inform a front-end that it will<br>
respond to a "scanning complete" event by terminating the scan, leaving<br>
valid data in the channel to be picked up. These semantics could, I<br>
believe, be fairly simply described by a simple matrix that answered<br>
questions like "does this interrupt the acquisition, or merely modify it",<br>
and "does this leave valid or invalid data in the output stream"?<br>
<p>
Of course, that's not at all an exhaustive list of those semantic points,<br>
but I hope it illustrates how some bracketed answers to simple questions<br>
would allow a front-end to reasonably determine how to present event<br>
triggers to the user, and when.<br>
<p>
If you like, all of these things can be thought of as simple extensions to<br>
the existing configuration/option mechanism, with a couple of added<br>
dimensions: time (ie: when the option should be 'active') and consequence<br>
(ie: what happens as a result of the option, in software-understandable<br>
representation).<br>
<p>
Okay. That's my idear. To the wolves with it, then.<br>
<p>
<pre>
--
   Tripp Lilley + Innovative Workflow Engineering, Inc. + (<a href="mailto:tripp@iweinc.com">tripp@iweinc.com</a>)
------------------------------------------------------------------------------
  "As for two years from now... who knows where it'll be. I think we'll
   ideally be doing a lot of the same stuff, but maybe with spell checking."
<p>
-- Rob Malda (Commander Taco of <a href="http://slashdot.org">http://slashdot.org</a>)
   in <a href="http://www.it.fairfax.com.au/990216/industry/it1.html">http://www.it.fairfax.com.au/990216/industry/it1.html</a>
<p>
<p>
<p>
<pre>
--
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
</pre>
<!-- body="end" -->
<p>
<ul>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0156.html">Wolfgang Goeller: "Re: Acer scanners"</a>
<li> <b>Previous message:</b> <a href="0154.html">Darren Marshall: "Re: Primax for Linux - temp. down"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>