> I made a proposal to handle compatibility, to wit:
Not really. The point is, that o.k., you can have any old frontend work with
any new driver by falling back to raw transfer mode, i.e. requiring support
for one of the now existing formats.
But this does not cover two important points:
1. Medium-Old frontends that do not know format xxx together with a driver
that does. Those frontends cannot do anything reasonable with the data
the driver offers in format xxx.
If the data can be transferred as raw data, this ensures interoperability,
but you can't use the format xxx the source has at all, which might have
advantages. And there are the cases, where the data is non-image for
example, and thus can't be transferred as raw anyway.
Yes - the frontend can save it blindly (which is the usual thing you want
to do to non-raw data anyway), but it cannot tell the user what it will
be saving, so he can decide whether it is worth the bother and eventually
what program he will have to invoke later to somehow display or otherwise
make sense of the data.
Using the mime type (or any other standardized descriptive text) together
with a single frametype has a big advantage: The "wit" to know what
a frametype actually contains is completely inside the backend.
No frontend, even an outdated one, needs to know the type to be able to
present it to the user in a human-readable way.
This is just like the options work: Their names show the _user_ what they
mean. The frontend has no idea about that (execpt for the well-known ones,
where the frontend can optionally be smart about them).
The very same mechanism goes for the frametype. If it is something the
frontend knows and can be smart about - fine. If not, it can forward
the "brainwork" to the user. But for that it needs something the user
can make sense of. It needs something like "image/jpeg" and not
"Frametype 45". It would be just like if we numbered our options
and told the frontends to keep up with the descriptions, if we
just added frametypes.
2. The last described problem could be handled by updating a mapping list
that is used by the frontend, when types are added.
However this requires a centralized control instance that gives out frame
types and takes care to update the database and some reasoning within the
backend distributions (which I assume to become decentralized, once
manufacurers pick up on SANE) to make sure only the most recent, and only
complete mapping lists are distributed.
I do think, that centralized control over often-changing stuff should be
avoided. It adds unnecessary buerocracy.
Moreover - either we keep tight control over what frametypes will be allowed
in and thus keep the database size at bay (thus disguesting some users
that want to do the stranger stuff), or it will quickly blow up to a size,
where we have reinvented mime.
> ** Once the well-known format option is added, new "advanced" frame formats
> ** can be added liberally without ever again breaking compatibility.
Note, that the format might change within a series of frames from one
sane_start(). Typical situation would be the batch scanning discussed
recently. A well known option can be used to preselect a given format,
but hardware contrains may e.g. demand to transmit the page thumbnail
uncompressed, and rest compressed.
This also applies to trying to handle barcodes in options. There could be
multiple barcodes interspersed with image data.
CU, Andy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> =
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com