> Now we see demand for transferring data that is not accurately described by
> getparm. Thus I propose to do the simple thing and basically ignore getparm
> stuff and just transfer some streamed data.
>
> Now this alone would be not too good, as it leaves no idea what the data
> and its format actually is.
> Thus I propose to add a generic content description system for such data.
> Mime seems like a good choice, as said above.
Mime would just tell you what sort of data stream it is but not
anything about the data itself. You would still have to get
the associated parameters in some other way. Not only the standard
parameters, but possibly also others (like exposure time). To do this
in a truly general way one could use XML.
> 2. Add a single bew frametype that announces the transmission of arbitrarily
> formatted data. Add two identification fields somewhere that give the
> mimetype and optionally a proposed filename for the data, so one can
> correctly detect and handle the type of data.
Given the mimetype and filename you now know how to dump the data to a
file in a format of your pleasing, but nothing more.
What I'm saying is, the mimetype stuff is more general but not general
enough. Perhaps in the future we can use XML for the communication
between backend and frontend, and we can use Netscape 9.0 as a
frontend to surf our scanner with. But for the more immediate future,
what I would like to see is a more incremental upgrade to the current
standard (perhaps better call it 1.1 instead of 2.0). That is, to just
add some new frame formats and well known options.
-- -- Ewald
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com