W3C home > Mailing lists > Public > www-tag@w3.org > January 2002

Re: Is "simplicity" a useful architectural constraint?

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
Message-ID: <20020102174705.A2070@waka.ebuilt.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:03 GMT