>>> = Tim Waugh
>> = Adam Richter
> = Tim Waugh
[...]
>> [...] by including the length bytes, we are
>> compatible with the USB practice and it is easier to write user
>> level utilities to do things like identify which printers have
>> incorrect length values (e.g., to catalog that information over the
>> net).
>I agree that it would be desireable to include the length bytes.
Great!
>In the vast majority of cases, one of the two bytes will be zero. You
>don't see a problem with that, for programs that are expecting an
>ASCII string?
I expect the updated versions of existing programs to skip
the first two bytes, especially since, according the kernel code,
that count is not always reliable anyhow. That's not a big change,
and should not provoke any new null termination problems.
>> The current format of autoprobe contains line feeds and only
>> long field names. I would think that any program that currently
>> uses it will have to be updated either way, although there are few
>> programs at this point.
>Not so again. The current format is 'just like' a length-fieldless
>IEEE 1284 Device ID, in that it can be parsed in exactly the same
>way. The line feeds don't matter because parsers need to ignore white
>space (IEEE 1284 even says this).
You have the logic backwards. The current format is a
well defined subset of valid IEEE 1284 strings. So, current parsers
of that format probably are not written to handle all possible
IEEE 1284 strings. Switching to passing the actual ID string,
whether we include the length bytes or not, will require these
parses to handle possibilities that they did not previous need to
handle.
>If you think that having the length field in is more important than
>keeping compatibility, you need to seek out the authors of any
>programs that will be affected.
From my previous paragraph, you should now be understand why
I say that passing the raw printer string without the length bytes
will most likely not "keep compatability" (i.e., it will probably
require client program regardless of whether length bytes are included).
The only programs that you so far have suggested may be effected are
distribution specific. I'm willing to seek our the authors of any
programs that will be effected, at least in the sense that I'm willing
to post a notice to linux-kernel about it and to help those authors.
If this is acceptable to you, I can make a new patch against
2.4.1-pre8 if that would help.
>> (The programs that I want are a simple facility for sending the IEEE
>> 1284 data to a public network database so distribution maintainers
>> could notice new device ID's as they appear and a variant of this
>> that would generate printcap entries on the fly).
>Good idea. :-)
Thanks.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed Jan 17 2001 - 04:59:30 EST