[cap-talk] Scope/span of capability systems

James A. Donald jamesd at echeque.com
Tue Mar 3 16:58:13 EST 2009

Marcus Brinkmann wrote:
 > In a world where we can't even agree on compatible
 > data formats, I see little chance to agree on
 > compatible capability interfaces, which have
 > potentially a much higher degree of complexity.

The low level standards were agreed back in the early
days of the internet, where all the key engineers could,
and regularly did, meet around a coffee table.
Committees and consensus do not scale.  The bigger they
are, the worse they perform.  As the internet has grown
larger, committees have become ever more bureaucratic,
rigid, stupid, incompetent, and slower.  Even though
many of the individuals in a large committee may be very
smart, the committee as a whole is apt to be moronic.

Even if you have centralized authority, as at Microsoft,
as the number and complexity of interfaces multiplies,
chaos and disaster is apt to ensue, leading to the
problem of DLL Hell.

DLL hell was successfully addressed with Microsoft
Interface Definition Language (MIDL).  This allows
anyone, anywhere, to specify an interface without
consulting anyone, and the MIDL compiler proceeds to
generate protocol negotiation code that guarantees that
if any two programs successfully connect using an
interface specified in Midl, they have been compiled
using the same interface definition.  Instead of
Microsoft specifying a protocol, they specified a run
time protocol negotiation process.

Unfortunately MIDL/IDL/COM was designed for calls within
a single address space and a single thread -it defines
function interfaces, not message formats.  It worked
great for this problem, but their efforts to extend it
to inter thread, inter process, and across network calls
varied from bad to catastrophic.

Google's protobuf is designed to work between threads
and over IPC - it is a message specification protocol,
but lacks the key feature of MIDL:  Protocol negotiation
- no run time guarantee that data was serialized the way
it will be deserialized, no run time guarantee that
server and client were compiled  using header files
generated from the same interface definition file file.

What we need is something like MIDL, but defining
messages, rather than function interfaces, and which,
like MIDL, generates code that guarantees that if a
connection is made, both sides are compiled the same
interface definition, without the existence of new
definitions crippling the behavior of old definitions
in mixed environments.

More information about the cap-talk mailing list