On Wed, 26 Jul 2000, Khimenko Victor wrote:
> > A properly designed protocol would have had support for this sort of
> > extension to existing facilities, without inventing whole new dialects.
> > In this case, probably the lock & unlock commands for removable media -
> > just add a "password" field - **and include this in the standard so no
> > other vendor uses the same field for something else, or vice versa**.
>
> This is not THAT simple. Not the whole world is hard drives. Especially
> with SCSI world.
So what? Whatever you are inventing, it should use a standard protocol.
Even if it has to be a new protocol.
> > If I wanted to add a new listing mode to `ls' for some reason, should I
> > add a new switch to ls's vocabulary, or invent `newls'?
>
> And if I need C comiler I hardly want to add switch --cc to ls - better to
> invent gcc :-)
That's what I mean: for a new feature to an existing part of the protocol,
extend that part. If it's genuinely a new area the protocol hasn't handled
before, you will need a new command - so make that part of the standard.
Can you imagine if we had one distro shipping with gcc being "Great
Cleanup Command", another with the C compiler, and a third where gcc as
root is "reformat all disks"?
> > Alternatively, if I really needed a new command for my new feature - drill
> > holes in disk, say - I get it included in the next revision of the
> > standard.
>
> What about new command to change resolution in scanner ?
It's a new command. Put it in the standard.
> > That way, all you ever need is the latest ATA-* driver.
>
> Which in turn will include knowleadge about scanners and photo-cameras.
> No, thnx.
NO. The ATA-* driver does NOT need to know what a scanner is - only that
the scanner commands are valid ones now.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:21 EST