kopia lustrzana https://gitlab.com/sane-project/website
522 wiersze
24 KiB
HTML
522 wiersze
24 KiB
HTML
|
<!-- received="Sat Aug 14 17:14:49 1999 PDT" -->
|
||
|
<!-- sent="Sun, 15 Aug 1999 02:17:31 +0200 (MEST)" -->
|
||
|
<!-- name="becka@rz.uni-duesseldorf.de" -->
|
||
|
<!-- email="becka@rz.uni-duesseldorf.de" -->
|
||
|
<!-- subject="SANE V2 - past discussions. A summary." -->
|
||
|
<!-- id="m11FnzQ-000CDTC@hades.beck-sw.de" -->
|
||
|
<!-- inreplyto="199908141750.KAA02998@icarus.com" -->
|
||
|
<title>sane-devel: SANE V2 - past discussions. A summary.</title>
|
||
|
<h1>SANE V2 - past discussions. A summary.</h1>
|
||
|
<a href="mailto:becka@rz.uni-duesseldorf.de"><i>becka@rz.uni-duesseldorf.de</i></a><br>
|
||
|
<i>Sun, 15 Aug 1999 02:17:31 +0200 (MEST)</i>
|
||
|
<p>
|
||
|
<ul>
|
||
|
<li> <b>Messages sorted by:</b> <a href="date.html#151">[ date ]</a><a href="index.html#151">[ thread ]</a><a href="subject.html#151">[ subject ]</a><a href="author.html#151">[ author ]</a>
|
||
|
<!-- next="start" -->
|
||
|
<li> <b>Next message:</b> <a href="0152.html">Nick Lamb: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
||
|
<li> <b>Previous message:</b> <a href="0150.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
||
|
<li> <b>In reply to:</b> <a href="0147.html">Stephen Williams: "Re: [Fwd: Re: Discussion about SANE and TWAIN...]"</a>
|
||
|
<!-- nextthread="start" -->
|
||
|
<li> <b>Next in thread:</b> <a href="0155.html">Nick Lamb: "Re: SANE V2"</a>
|
||
|
<li> <b>Reply:</b> <a href="0155.html">Nick Lamb: "Re: SANE V2"</a>
|
||
|
<li> <b>Reply:</b> <a href="0165.html">Oliver Rauch: "Re: SANE V2 - past discussions. A summary."</a>
|
||
|
<!-- reply="end" -->
|
||
|
</ul>
|
||
|
<!-- body="start" -->
|
||
|
Hi !<br>
|
||
|
<p>
|
||
|
<i>> a SANE driver for. However, I need some more complete frame types as</i><br>
|
||
|
<i>> this scanner produces JFIF and TIFF/G4 images (simultaneously) and I</i><br>
|
||
|
<i>> would *like* to just pass the JFIF data as a coded SANE frame.</i><br>
|
||
|
<i>> Once I do that, I'll have access to some high-speed document scanners</i><br>
|
||
|
<i>> that I would also like to write drivers for.</i><br>
|
||
|
<i>> Is there a place where I can see a draft of what SANE 2.x will contain,</i><br>
|
||
|
<i>> so that I (we) can comment?</i><br>
|
||
|
<p>
|
||
|
O.K. - I will forward all mails I and David exchanged on that topic.<br>
|
||
|
Maybe I'll add some rant at the end as well, reviewing them from a<br>
|
||
|
greater distance.<br>
|
||
|
Such rant will be marked with ###.<br>
|
||
|
<p>
|
||
|
Here you are:<br>
|
||
|
<p>
|
||
|
------------ snip --------------<br>
|
||
|
<p>
|
||
|
O.k. - as the recent interest in doing compressed file transmission and<br>
|
||
|
a TWAIN bridge show demand for that, I have written up a little summary on<br>
|
||
|
what has been thought of as new features SANE 2.0<br>
|
||
|
<p>
|
||
|
<p>
|
||
|
A. From the SANE docs: LEVEL2:<br>
|
||
|
------------------------------<br>
|
||
|
<p>
|
||
|
** Tue Jun 3 10:22:33 1997<br>
|
||
|
<p>
|
||
|
Here are some ideas under discussion for the next major revision of<br>
|
||
|
the SANE API:<br>
|
||
|
<p>
|
||
|
o Additional image data types, such as JPEG, MPEG, FlashPix, raw.<br>
|
||
|
These would be useful for devices that directly generate such<br>
|
||
|
formats (still cameras, for example). The raw image format could<br>
|
||
|
be used when no other format is applicable. This would allow to<br>
|
||
|
at least read and save the data in a file. This would probably<br>
|
||
|
have to be coupled with adding a function that lets a frontend<br>
|
||
|
tell the backend what level it supports, something like<br>
|
||
|
sane_set_level (int max_supported_level).<br>
|
||
|
[Based on suggestion by Andreas Beck <<a href="mailto:becka@ggi-project.org">becka@ggi-project.org</a>>]<br>
|
||
|
<p>
|
||
|
o Support for other multimedia types, such as audio. This probably<br>
|
||
|
would also require adding a write() interface to the SANE API.<br>
|
||
|
[Suggested by Erik Troan <<a href="mailto:ewt@redhat.com">ewt@redhat.com</a>>.]<br>
|
||
|
<p>
|
||
|
B. From some private communications I found in my backlog:<br>
|
||
|
----------------------------------------------------------<br>
|
||
|
<p>
|
||
|
** Tue Oct 20 22:02:03 1998: Andy:<br>
|
||
|
<p>
|
||
|
<i>> - when will there be JPEG support in the SANE interface? i guess</i><br>
|
||
|
<i>> other camera (such as the Kodak ones?) also use a format</i><br>
|
||
|
<i>> that's close to JPEG...</i><br>
|
||
|
<p>
|
||
|
We should finally add that.<br>
|
||
|
<p>
|
||
|
My idea about adding it would be to increase the version number, which<br>
|
||
|
can be queried at sane_init() time.<br>
|
||
|
<p>
|
||
|
If the frontend finds a sufficiently high version, it would assume<br>
|
||
|
that the SANE_Parameters struct is extended by a few fields like:<br>
|
||
|
<p>
|
||
|
SANE_String mime_type;<br>
|
||
|
SANE_String suggested_filename;<br>
|
||
|
<p>
|
||
|
This would effectively take care of all possible fileformats.<br>
|
||
|
<p>
|
||
|
The frontend code would have to be changed a bit like this:<br>
|
||
|
<p>
|
||
|
if (strcmp(param.mimetype,"application/SANE"))<br>
|
||
|
save_directly_to_file(<br>
|
||
|
make_path_suitable_for_host_os(<br>
|
||
|
param.suggested_filename)));<br>
|
||
|
else<br>
|
||
|
do_the_same_as_before();<br>
|
||
|
<p>
|
||
|
This would also take care of the second suggestion in the file to use SANE<br>
|
||
|
for arbitrary datatypes.<br>
|
||
|
<p>
|
||
|
File size could be handled in a compatible way, by setting bytes_per_line<br>
|
||
|
and lines accordingly, that is usually to something like fsize(),1 or<br>
|
||
|
1,fsize().<br>
|
||
|
<p>
|
||
|
### using the lines==0 semantics that were resevred for handscanners, <br>
|
||
|
### we could handle yet unknown filesizes, which might occur for<br>
|
||
|
### compressed data formats.<br>
|
||
|
<p>
|
||
|
This would only be a minor modification to frontends and backends<br>
|
||
|
(even old frontends would handle new-style data somewhat correctly,<br>
|
||
|
if they would save it to a file directly without trying to convert/<br>
|
||
|
interpret it first). Most of our current front-ends afaik do a very<br>
|
||
|
simplistic "convert to pnm" which could easily be undone afterwards<br>
|
||
|
by a small script that simply removes the header.<br>
|
||
|
<p>
|
||
|
<p>
|
||
|
** Fri Oct 23 18:58:38 1998: David:<br>
|
||
|
<p>
|
||
|
What I'd like to see is the backend declaring what image format(s) it<br>
|
||
|
supports. Similarly, the frontend would say what image format it<br>
|
||
|
wants. Then you have a set of library routines that are filters,<br>
|
||
|
e.g., (input: JPG, output: RAW), (input: RAW, output: JPG). So if<br>
|
||
|
there is a mismatch between backend and frontend format, you call a<br>
|
||
|
library routine that will construct a suitable pipeline of filters.<br>
|
||
|
<p>
|
||
|
The biggest issue is probably what to do for filters that need<br>
|
||
|
parameters (such as JPG smoothing & quality settings).<br>
|
||
|
<p>
|
||
|
---david<br>
|
||
|
<p>
|
||
|
** Sat Oct 24 12:42:25 1998: Andy:<br>
|
||
|
<p>
|
||
|
<i>> What I'd like to see is the backend declaring what image format(s) it</i><br>
|
||
|
<i>> supports.</i><br>
|
||
|
<p>
|
||
|
O.K. - as the user might want to select the format (regardless of what his<br>
|
||
|
frontend will understand), I suggest to just introduce a standard option<br>
|
||
|
for that.<br>
|
||
|
<p>
|
||
|
<i>> Similarly, the frontend would say what image format it wants.</i><br>
|
||
|
<p>
|
||
|
I'd say it should parse the constraint list of said option and preselect<br>
|
||
|
the best of those it understands.<br>
|
||
|
<p>
|
||
|
<i>> Then you have a set of library routines that are filters,</i><br>
|
||
|
<i>> e.g., (input: JPG, output: RAW), (input: RAW, output: JPG). So if</i><br>
|
||
|
<i>> there is a mismatch between backend and frontend format, you call a</i><br>
|
||
|
<i>> library routine that will construct a suitable pipeline of filters.</i><br>
|
||
|
<p>
|
||
|
Yes. Possible, though it might be hard to actually determine what the best<br>
|
||
|
path would be, i.e. which frontend-format/backend-format combination<br>
|
||
|
gives best quality. This might even depend on other source-options.<br>
|
||
|
<p>
|
||
|
<i>> The biggest issue is probably what to do for filters that need</i><br>
|
||
|
<i>> parameters (such as JPG smoothing & quality settings).</i><br>
|
||
|
<p>
|
||
|
Regarding the filters issue I'd suggest to make use of one or more<br>
|
||
|
"passthrough" pseudo middle-ends that simply add to the abovementioned<br>
|
||
|
option and add their own options in as required by the conversion.<br>
|
||
|
<p>
|
||
|
Let's make up an example:<br>
|
||
|
<p>
|
||
|
We have a camera that outputs image/foo or image/bar type data on request.<br>
|
||
|
<p>
|
||
|
The frontend only understands image/gif and application/sane.<br>
|
||
|
<p>
|
||
|
We have a middle-end that can convert image/foo|bar to image/gif,<br>
|
||
|
image/jpeg, image/bla and application/sane.<br>
|
||
|
<p>
|
||
|
Now what happens:<br>
|
||
|
<p>
|
||
|
The frontend starts up and queries the camera for options. It sees the<br>
|
||
|
special option "transmission-format" and checks its constraint list.<br>
|
||
|
<p>
|
||
|
As there is no match between understood formats and transmittable formats,<br>
|
||
|
it tries (after asking the user ?) to reopen the selected source through<br>
|
||
|
the filter middleend.<br>
|
||
|
<p>
|
||
|
It again parses the special option which will now show foo,bar,gif,jpeg,bla<br>
|
||
|
and sane.<br>
|
||
|
Now it picks those it understands (in preferred order) and places them at<br>
|
||
|
the top of the constraint list and somehow marks them to the user (say by<br>
|
||
|
adding a "*" on text frontends or by making them green or whatever.<br>
|
||
|
<p>
|
||
|
Now to the user the select list looks like "sane,gif,foo,bar,jpeg,bla".<br>
|
||
|
<p>
|
||
|
Now say the user wants to have jpeg for some reason. So he selects the<br>
|
||
|
appropriate option. The middleend sees that, selects the most suitable<br>
|
||
|
source format (foo or bar) on the source and adds the required conversion<br>
|
||
|
options to the option list.<br>
|
||
|
<p>
|
||
|
If the user now asks for a scan, this request is passed through the<br>
|
||
|
middleend which sets up its filters in sane_read and builds a suitable<br>
|
||
|
parameter struct (as I suggested).<br>
|
||
|
<p>
|
||
|
The frontend sees (from the parameter struct) that is doesn't know the<br>
|
||
|
selected format, so it prompts the user for a filename (default from<br>
|
||
|
params) and just saves it.<br>
|
||
|
<p>
|
||
|
If the user had selected a known format, the frontend would proceed as<br>
|
||
|
usual, displaying the image etc.<br>
|
||
|
<p>
|
||
|
A reasonable addition to many frontends would be to have some kind of<br>
|
||
|
"mime.types" file (maybe even use it ?) that can be used to direct output<br>
|
||
|
to other programs as described there.<br>
|
||
|
<p>
|
||
|
Say if we get a audio/wav file, we parse mime.types and ask<br>
|
||
|
"I don't know mime-type audio/wav - what should I do ?<br>
|
||
|
1. save to file<br>
|
||
|
2. use mime.types (will run %s to display file)<br>
|
||
|
3. cancel operation"<br>
|
||
|
<p>
|
||
|
** Wed Oct 28 07:11:49 1998: david:<br>
|
||
|
<p>
|
||
|
Hmmh, I see where you're coming from as far as support for different<br>
|
||
|
image data formats are concerned, but I'm not sure I like what you're<br>
|
||
|
proposing. Here are some constraints I think we (ideally) should<br>
|
||
|
adhere to:<br>
|
||
|
<p>
|
||
|
- existing frontends should continue to work (both in binary<br>
|
||
|
form and in source form)<br>
|
||
|
<p>
|
||
|
- existing backends should continue to work (both in binary<br>
|
||
|
form and in source form)<br>
|
||
|
<p>
|
||
|
- the user should not have to worry about image transmission<br>
|
||
|
format<br>
|
||
|
<p>
|
||
|
I think we should agree on a set of image formats supported by SANE.<br>
|
||
|
E.g., format 0 is the existing "raw" format and uses a default file<br>
|
||
|
extension of ".pnm". Format 1 could be GIF with file extension ".gif"<br>
|
||
|
etc.<br>
|
||
|
<p>
|
||
|
Suppose we introduce a new call:<br>
|
||
|
<p>
|
||
|
SANE_Status sane_set_format (SANE_Word *format);<br>
|
||
|
<p>
|
||
|
When calling the value *FORMAT gives the format the frontend wants the<br>
|
||
|
image data in. A special value of SANE_IMAGE_FORMAT_ANY indicates<br>
|
||
|
that the frontend can accept any format (as is the case for scanimage,<br>
|
||
|
for example). Upon returning, *FORMAT gives the format that the<br>
|
||
|
backend is actually returning. If the returned format doesn't match<br>
|
||
|
the wanted format, the frontend can either accept the backends choice<br>
|
||
|
(if the frontend can handle the format), abort with an error, or try<br>
|
||
|
another sane_set_format() call with a different wanted format to see<br>
|
||
|
if that format works better.<br>
|
||
|
<p>
|
||
|
Let's try your example:<br>
|
||
|
<p>
|
||
|
- camera returns either FOO or BAR format<br>
|
||
|
- the conversion meta-backend "cnv" can convert from FOO or BAR<br>
|
||
|
to GIF, JPEG, and RAW<br>
|
||
|
<p>
|
||
|
Let's consider different frontends:<br>
|
||
|
<p>
|
||
|
- In the case of GIMP, you always want RAW format so you'd<br>
|
||
|
call sane_set_format() with a parameter of<br>
|
||
|
SANE_IMAGE_FORMAT_RAW and if you don't get what you ask<br>
|
||
|
for, you abort. Since "cnv" can convert both FOO and BAR<br>
|
||
|
to RAW, no problem exists.<br>
|
||
|
<p>
|
||
|
- In the case of scanimage, you'd let the user specify the<br>
|
||
|
format. By default, you'd presumably pick the format based<br>
|
||
|
on the filename extension (such as ".jpg") or through an<br>
|
||
|
explicit option. Then scanimage performs the appropriate<br>
|
||
|
sane_set_format() call. If the user doesn't care about the<br>
|
||
|
format being used, scanimage could call sane_set_format()<br>
|
||
|
with a value of SANE_IMAGE_FORMAT_ANY which lets the backend<br>
|
||
|
pick the format that is most convenient (e.g., JPEG for a<br>
|
||
|
JPG camera).<br>
|
||
|
<p>
|
||
|
For example, if scanimage picks the JPEG format, cnv will<br>
|
||
|
detect that the camera can't deliver JPEG (the camera<br>
|
||
|
would return it's preferred format, e.g., FOO). It would<br>
|
||
|
then arrange for a translation from FOO to JPEG.<br>
|
||
|
<p>
|
||
|
Now, what happens if there is a version mismatch:<br>
|
||
|
<p>
|
||
|
- if an old frontend talks to a new backend, the backend can<br>
|
||
|
detect this since there won't be any calls to<br>
|
||
|
sane_set_format(). In this case, the backend defaults to<br>
|
||
|
returning the RAW format. If a backend doesn't support RAW<br>
|
||
|
(as might be the case for a JPEG camera), an old frontend<br>
|
||
|
would not be able to directly talk to such a backend.<br>
|
||
|
However, as long as a suitable conversion meta-backend<br>
|
||
|
is interspersed, things will work happily (the meta-backend<br>
|
||
|
sees the lack of a call to sane_set_format and defaults<br>
|
||
|
to returning RAW, independent of what the real backend<br>
|
||
|
delivers)<br>
|
||
|
<p>
|
||
|
- if a new frontend talks to an old backend the<br>
|
||
|
sane_set_format() call always returns RAW<br>
|
||
|
<p>
|
||
|
I think it would be nice to have a "cnv" meta-backend that would be<br>
|
||
|
fairly generic in that it would be easy to add new filters. The<br>
|
||
|
filters would either convert to or from RAW format, so there really<br>
|
||
|
isn't much of an issue as to how to construct an "optimal" pipe (since<br>
|
||
|
the pipe consists either of exactly 0, 1, or 2 elements).<br>
|
||
|
<p>
|
||
|
** From <a href="mailto:davidm@mostang.com">davidm@mostang.com</a> Fri Oct 30 06:54:23 1998<br>
|
||
|
<p>
|
||
|
Andy> O.K. - would you mind using the mime-type ?<br>
|
||
|
<p>
|
||
|
No, I think it makes some sense to use MIME.<br>
|
||
|
<p>
|
||
|
Andy> My idea was, that a backend that offers formats that take<br>
|
||
|
Andy> parameters also exports those as options.<br>
|
||
|
<p>
|
||
|
Seems reasonable.<br>
|
||
|
<p>
|
||
|
<i> >> Also, I think we may want to pick the name of the image format to</i><br>
|
||
|
<i> >> be identical to the default filename extension</i><br>
|
||
|
<p>
|
||
|
Andy> This is why I was proposing to have a type filed as well as a<br>
|
||
|
Andy> "suggested filename". The latter especially makes sense for<br>
|
||
|
Andy> picture archives or such.<br>
|
||
|
<p>
|
||
|
Can't you get the suggested filename from the mime database? There is<br>
|
||
|
an "exts" field. Besides, I'm not really sure having a suggested<br>
|
||
|
filename extension is that important. I don't particularly like<br>
|
||
|
programs that insist on using specific extensions (though it's OK if<br>
|
||
|
the _default_ to a sensible extension).<br>
|
||
|
<p>
|
||
|
Andy> Do we want SANE to be able to carry totally foreign or weird<br>
|
||
|
Andy> formats like say audio ?<br>
|
||
|
<p>
|
||
|
I think we shouldn't do anything that precludes this, but I also don't<br>
|
||
|
think it's anything that's worth spending a lot of effort on right<br>
|
||
|
now. Introducing realtime issues could quickly make SANE so<br>
|
||
|
complicated that it's too bloated for simple scanning. On the other<br>
|
||
|
hand, if for some reason video acquisition through SANE suddenly<br>
|
||
|
becomes a hot topic, we may want to be able to have at least some<br>
|
||
|
basic audio acquisition support. But I would say we worry about this<br>
|
||
|
when we have a real need for it.<br>
|
||
|
<p>
|
||
|
To summarize our discussion: I don't have much of a problem using the<br>
|
||
|
"transmission-format" well-known option and whoever does the actual<br>
|
||
|
work, gets the final say. If you want to do it (I won't have time any<br>
|
||
|
time soon), go wild! Please be sure to update sane.tex etc as well so<br>
|
||
|
the docs stay in sync with the code (oh, I also think we should run<br>
|
||
|
things by sane-devel when there is a detailed proposal).<br>
|
||
|
<p>
|
||
|
** From <a href="mailto:becka@rz.uni-duesseldorf.de">becka@rz.uni-duesseldorf.de</a> Fri Oct 30 14:11:50 1998<br>
|
||
|
<p>
|
||
|
<i>> Andy> O.K. - would you mind using the mime-type ?</i><br>
|
||
|
<i>> No, I think it makes some sense to use MIME.</i><br>
|
||
|
<p>
|
||
|
O.K. - so we consider that as "decided".<br>
|
||
|
<p>
|
||
|
<i>> Andy> My idea was, that a backend that offers formats that take</i><br>
|
||
|
<i>> Andy> parameters also exports those as options.</i><br>
|
||
|
<i>> Seems reasonable.</i><br>
|
||
|
<p>
|
||
|
O.K. - see my comments below.<br>
|
||
|
<p>
|
||
|
<i>> >> Also, I think we may want to pick the name of the image format to</i><br>
|
||
|
<i>> >> be identical to the default filename extension</i><br>
|
||
|
<i>> Andy> This is why I was proposing to have a type filed as well as a</i><br>
|
||
|
<i>> Andy> "suggested filename". The latter especially makes sense for</i><br>
|
||
|
<i>> Andy> picture archives or such.</i><br>
|
||
|
<i>></i><br>
|
||
|
<i>> Can't you get the suggested filename from the mime database?</i><br>
|
||
|
<p>
|
||
|
Yes, I think you can. But that wasn't, what I was trying to achieve with<br>
|
||
|
that. I wanted a full "suggested filename". That is, it should return<br>
|
||
|
"nice_picture_of_something.jpg". This is probably reasonable for<br>
|
||
|
transferring<br>
|
||
|
pictures from archives or such. You automatically get a reasonable filename.<br>
|
||
|
<p>
|
||
|
<i>> There is an "exts" field. Besides, I'm not really sure having a suggested</i><br>
|
||
|
<i>> filename extension is that important. I don't particularly like</i><br>
|
||
|
<i>> programs that insist on using specific extensions (though it's OK if</i><br>
|
||
|
<i>> the _default_ to a sensible extension).</i><br>
|
||
|
<p>
|
||
|
Yes. That is how I see it, too. You should get a reasonable default, but any<br>
|
||
|
program insisting or not asking for confirmation is broken IMO.<br>
|
||
|
<p>
|
||
|
<i>> Andy> Do we want SANE to be able to carry totally foreign or weird</i><br>
|
||
|
<i>> Andy> formats like say audio ?</i><br>
|
||
|
<i>></i><br>
|
||
|
<i>> I think we shouldn't do anything that precludes this, but I also don't</i><br>
|
||
|
<i>> think it's anything that's worth spending a lot of effort on right</i><br>
|
||
|
<i>> now.</i><br>
|
||
|
<p>
|
||
|
Yes. Though I thought with using MIME, it should be pretty trivial.<br>
|
||
|
<p>
|
||
|
<i>> Introducing realtime issues could quickly make SANE so</i><br>
|
||
|
<i>> complicated that it's too bloated for simple scanning.</i><br>
|
||
|
<p>
|
||
|
Yes. I do not care for things like "streaming" audio/video. This is far too<br>
|
||
|
complex for SANE and requires too many changes. Just that you can transfer<br>
|
||
|
anything that could also be in a file and doesn't have other prerequisites.<br>
|
||
|
<p>
|
||
|
A bit of "netscape for scanners", you know. If someone build a file archive<br>
|
||
|
using SANE, he should be able add a few sound files or whatever, too.<br>
|
||
|
<p>
|
||
|
<i>> On the other hand, if for some reason video acquisition through SANE</i><br>
|
||
|
<i>> suddenly becomes a hot topic,</i><br>
|
||
|
<p>
|
||
|
I will probably write a driver for the Permedia II Graphics card I have<br>
|
||
|
which includes a Video grabber. But I won't care for live video, just for<br>
|
||
|
stills. SANE is just not suited to do that.<br>
|
||
|
<p>
|
||
|
A read-type interface isn't good. Video demands high bandwidth, and is thus<br>
|
||
|
best achieved via a mmap-type interface.<br>
|
||
|
<p>
|
||
|
<i>> we may want to be able to have at least some basic audio acquisition</i><br>
|
||
|
<i>> support. But I would say we worry about this when we have a real need</i><br>
|
||
|
<i>> for it.</i><br>
|
||
|
<p>
|
||
|
Yes. I'd say for now, everything that resembles a file transfer is o.k.<br>
|
||
|
Anything needing special transmission semantics like guaranteed bandwidth,<br>
|
||
|
bandwidth negotiation, etc. is out of bounds for now.<br>
|
||
|
<p>
|
||
|
------------ snap --------------<br>
|
||
|
<p>
|
||
|
O.K. - looks like I hadn't much to rant about.<br>
|
||
|
<p>
|
||
|
So the question is: Do you like the following general ideas:<br>
|
||
|
<p>
|
||
|
1. Add a well-known option to backends that can transfer in nonstandard<br>
|
||
|
formats, which allows to choose the format. This option shall be there, <br>
|
||
|
even if it only has one possible setting, as it is used to identify backends<br>
|
||
|
that use nonstandard formats.<br>
|
||
|
<p>
|
||
|
2. Write one or more filtering "middleends", that - similar to the net<br>
|
||
|
front-/backend - pass through a given source. Such Middleends would parse<br>
|
||
|
and upgrade the option described in 1 to hold all native formats _plus_<br>
|
||
|
all formats the middleend can convert the native formats to.<br>
|
||
|
<p>
|
||
|
3. Frontends that support this extension shall scan for the well-known<br>
|
||
|
option and mark up and default-select the format that is most convenient<br>
|
||
|
to them.<br>
|
||
|
<p>
|
||
|
4. Add a single new frametype SANE_MIME which describes a stream that looks<br>
|
||
|
like the output of a CGI-script, that would transfer the corresponding<br>
|
||
|
information. That is:<br>
|
||
|
<p>
|
||
|
------ snip --------<br>
|
||
|
Content-type: text/html<br>
|
||
|
More-headers: some extra hints<br>
|
||
|
<p>
|
||
|
data_in_free_streaming_format_until_eof.<br>
|
||
|
------ snap --------<br>
|
||
|
<p>
|
||
|
All headers are optional. Thus the minimal transmission consists of<br>
|
||
|
a single newline character (which serves as a header/body separator) <br>
|
||
|
followed by the raw data. It is not recommended to do so, though. <br>
|
||
|
At least Content-type: should be given.<br>
|
||
|
<p>
|
||
|
I propose two such headers that might be commonly used and should thus be<br>
|
||
|
parsed by the frontend. They are the same as what MIME-aware mailhandlers <br>
|
||
|
set for attachments :<br>
|
||
|
<p>
|
||
|
a) Content-type: mimetype/subtype[; optional_attribute=value]<br>
|
||
|
<p>
|
||
|
This header specifies the mimetype of the data that follows. The frontend<br>
|
||
|
should use that to look the type up in mime.types and prompt the user<br>
|
||
|
whether to "Save to file" (for which the extension info from the mime<br>
|
||
|
database is useful), "Open using application %s." (also from mime.types),<br>
|
||
|
or to cancel the transmission.<br>
|
||
|
Some frontends may also add "use internal viewer".<br>
|
||
|
<p>
|
||
|
Frontends that do not want to care about mime or asking the user should<br>
|
||
|
simply save away the stream "as-is" to a file, which allows for later <br>
|
||
|
processing with mime-aware tools.<br>
|
||
|
<p>
|
||
|
b) Content-Disposition: attachment; filename="suggested_filename"<br>
|
||
|
<p>
|
||
|
This header seems to be used to suggest a filename to mime-aware programs.<br>
|
||
|
Note, that the filename should be mangled by the frontend to conform to <br>
|
||
|
OS-dependent conventions and that care should be taken to:<br>
|
||
|
- Avoid security breaches using path separators, .., absolute paths, ... <br>
|
||
|
- Avoid similar attacks directed at creating files like .rhosts or<br>
|
||
|
overwriting them.<br>
|
||
|
<p>
|
||
|
c) as the transport stream in SANE is assumed to be 8 bit clean (otherwise<br>
|
||
|
other frame formats won't work), I see little use for stuff like<br>
|
||
|
Content-Transfer-Encoding: base64<br>
|
||
|
and similar. <br>
|
||
|
<p>
|
||
|
5. As an alternative to the "inband" transmission suggested in 4., it would<br>
|
||
|
be possible to either add a new call to SANE or extend the get_parameters<br>
|
||
|
call to hold that information.<br>
|
||
|
Inband allows for an arbitrary number of Headers, while outband at getparm<br>
|
||
|
time seems a more natural approach from the code-flow and simplicity of<br>
|
||
|
parsing standpoint. In that case, we should simply limit ourselves to<br>
|
||
|
two strings containing mimetype and suggested filename.<br>
|
||
|
<p>
|
||
|
<p>
|
||
|
Comments very welcome.<br>
|
||
|
<p>
|
||
|
CU, ANdy<br>
|
||
|
<p>
|
||
|
<pre>
|
||
|
--
|
||
|
= Andreas Beck | Email : <<a href="mailto:andreas.beck@ggi-project.org">andreas.beck@ggi-project.org</a>> =
|
||
|
<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="0152.html">Nick Lamb: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
||
|
<li> <b>Previous message:</b> <a href="0150.html">Stephen Williams: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
||
|
<li> <b>In reply to:</b> <a href="0147.html">Stephen Williams: "Re: [Fwd: Re: Discussion about SANE and TWAIN...]"</a>
|
||
|
<!-- nextthread="start" -->
|
||
|
<li> <b>Next in thread:</b> <a href="0155.html">Nick Lamb: "Re: SANE V2"</a>
|
||
|
<li> <b>Reply:</b> <a href="0155.html">Nick Lamb: "Re: SANE V2"</a>
|
||
|
<li> <b>Reply:</b> <a href="0165.html">Oliver Rauch: "Re: SANE V2 - past discussions. A summary."</a>
|
||
|
<!-- reply="end" -->
|
||
|
</ul>
|