- From: Roy T. Fielding <fielding@ebuilt.com>
- Date: Wed, 2 Jan 2002 17:47:05 -0800
- To: Jeff Lowery <jlowery@scenicsoft.com>
- Cc: "'Duane Nickull'" <duane@xmlglobal.com>, "'Tim Bray'" <tbray@textuality.com>, www-tag@w3.org
There is no correspondence between good protocols and simple specification. There are some protocols that are simple to describe but, as a result, cause the number of interactions necessary to do anything via those protocols to be very complex. There are other protocols that are difficult to describe due to the number of potential states, but are simple in practice because the state machine to implement them is relatively flat. There are many specifications that are simply incomplete, and other specifications that are long because the wrong formalism was chosen. Likewise, many protocols have been designed with layers for "simplicity", only to find that those layers cause so much overhead, alignment, and fragmentation problems that an efficient implementation becomes hopelessly complex. I've never seen a good formal notation that was shorter than a specification without formalism. One is not a substitute for the other. I once wrote a 95 page Z specification of a boulevard stop -- the same protocol is described in two pages in the California driver's manual. Likewise, formalisms are notoriously bad for describing the workarounds necessary to deal with poor implementations. Ignore the size of the specification. What is important in an architecture is the complexity of an implementation and the complexity of its interactions with other components. ....Roy
Received on Wednesday, 2 January 2002 20:52:09 UTC