> Sorry, if I sound a little pissed, but it might help to read up a little on
> the history of SANE. You might wish to look at V 0.1 and the names in that
> spec before judging "the spirit" of it.
I know. That's why I'm sad that you (and apparently David) are proposing
to butcher SANE in the way you described. If you take the course you
originally proposed, I genuinely believe it will be the end of SANE.
MIME is not a solution to your problems, even the MIME types system is
probably overkill, but MIME itself is definitely *not* what SANE needs to
support the scanners we've been talking about on the list.
> Happy time hacking all of them in. Digital cameras are very creative in that
> area.
I'm not interested in having fairly bad support for digital cameras in SANE
when there's really good support for digital cameras in gPhoto. Since
we are now working toward TWAIN/Unix, it makes sense for gPhoto and SANE
to each implement TWAIN sources on top of their respective APIs.
> Flashpix, Photo-CD, and about any other file-format for the case of picture
> archives, which can as well be implemented as a SANE backend.
I want SCANNER ACCESS NOW EASY. I don't want CAT FOOD NOW CHEAP, or CAMERA
SUPPORT NOW MEDIOCRE or PHOTOS NOW STORED CENTRALLY
We *could* implement anything as a SANE backend, and I guarantee that you
will find at least one person who'll ask for HTML, MP3 and probably for
a new API better suited to the Amiga. I'm not interested in fantasy, I
want the next generation SANE to be a useful and effective tool.
It's worth stating here that right from the start I was suprised that
SANE had xcam, because the SANE API is exactly the wrong way to do that
sort of thing. No surprise for me when it was altogther the least used
feature of SANE. Now of course there's better support for the QuickCam
in other applications and APIs.
> With more intelligence being moved into the scanners, we might get
> text/plain or text/rtf in the future. TWAIN has provisions to read barcodes,
> so their translation is probably also directly provided by some scanners.
If the scanner wants to speak text, it's probably beyond the territory
we should sensibly stake out for SANE. At that point you're looking at a
whole new class of device IMHO.
> I would simply consider them undefined and filled with values that will
> allow for smooth transfer even with old code. They are of no interest to
> you for the transmission. And any external format like JPG will have the
> information we transfer outband for application/sane inband, that is,
> included in the file stream itself.
application/sane?
> > filename "Recommended file name (e.g. buttercup.jpg)"
> > Backends with appropriate information can recommend a filename for
> > storing this image on disk.
>
> Pardon me ? This is precisely what I was proposing ... ???
> Could you consider reading what others propose before judging ?
That was one option, the one you seemed to favour less, and for only a
small part of your proposal. I don't think "filename" will be used much
anyway, because most of the devices I can envision being used with
SANE don't have a useful filename to suggest.
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com