On Fri, 1 Aug 2003, Dave Butenhof wrote:
DB>Harti Brandt wrote:
DB>
DB>>I have to add only one remark: having optional features in a standard is
DB>>ok. It makes sense, although, while designing the optional feature to
DB>>think about the implications on existing or forthcoming applications. If
DB>>the amount of work needed for implementing the option outweights the
DB>>benefit (either because of complexity or because there are other ways to
DB>>do almost the same), then putting the option into the standard is bad. It
DB>>is bad (and not neutral), because it makes the standard 'thicker' and
DB>>raises the energy needed by 'outside' people to understand/implement it.
DB>>
DB>>
DB>Ah, but this overlooks the POLITICAL aspect of developing standards.
DB>While some of the options really stem from serious and reasonably
DB>objective technical concerns (like prioritized I/O, which can obsolete
DB>not merely kernel software but also intelligent I/O hardware and can be
DB>extraordinarily difficult to implement throughout a distributed I/O
DB>system), others are there simply because without the option some
DB>significant group would have voted "NO" and there might have been no
DB>standard at all.
Yes.
That again remembers me why ATM cells are 48 byte: the americans wanted 64
and the europeans wanted 32 (or was it the other way around). The met in
the middle :-) One should at least TRY to prevent useless stuff to slip
in.
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
yyyyyy@xxxxxxxxxxxxxxxxxxx, yyyyy@xxxxxxxxxxx
|