Okay, so I repeat much of the original vision of TWAIN and SANE (SANE
being, of course, far preferable to TWAIN because it's, well, sane).
However, there are a couple of areas in which I believe a 1.5 or 2.0
version of the SANE API needs "improvement" to become a more generic image
acquisition service. These are not fully fleshed-out thoughts, but are
random musings that occured to me in an unspecified location, dominated by
a preponderance of porcelain and plumbing.
* As mentioned in another thread, there needs to be support for image
sources which do not, themselves, know when to quit. Hand scanners were
the particular example, but any other sort of continuous-capture device
would fit the model.
* There ought to be a way to mark certain options as "having to be
configured per-scan". In other words, options that a software package
ought to prompt for, or otherwise set, each time the acquisition happens.
For an "Image::Grab" backend, for instance, the URL from which to grab,
and perhaps an image type, would make sense as things to be prompted for
before each acquisition.
Addressing the first point, it might make sense to define a generic
"event" model that allows a driver to specify to which events it will
respond during acquisition, and some simple semantics of its response. For
instance, a hand-scanner backend might inform a front-end that it will
respond to a "scanning complete" event by terminating the scan, leaving
valid data in the channel to be picked up. These semantics could, I
believe, be fairly simply described by a simple matrix that answered
questions like "does this interrupt the acquisition, or merely modify it",
and "does this leave valid or invalid data in the output stream"?
Of course, that's not at all an exhaustive list of those semantic points,
but I hope it illustrates how some bracketed answers to simple questions
would allow a front-end to reasonably determine how to present event
triggers to the user, and when.
If you like, all of these things can be thought of as simple extensions to
the existing configuration/option mechanism, with a couple of added
dimensions: time (ie: when the option should be 'active') and consequence
(ie: what happens as a result of the option, in software-understandable
representation).
Okay. That's my idear. To the wolves with it, then.
-- Tripp Lilley + Innovative Workflow Engineering, Inc. + (tripp@iweinc.com) ------------------------------------------------------------------------------ "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."-- Rob Malda (Commander Taco of http://slashdot.org) in http://www.it.fairfax.com.au/990216/industry/it1.html
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com