Re: Design principles

[Jonathan S. Shapiro]

On Sun, 2007-01-14 at 13:23 +0100, Pierre THIERRY wrote:
> With the recent discussions, and because, beyond the fruitful technical
> discussions about use cases, I probably disagree with Marcus on some of
> his critical goals for the HURD, I'd like to try to come up with an
> alternative design.

Pierre:

The system that you are starting to describe is called Coyotos. If this
is what you really want to accomplish, why not come join the Coyotos
project instead of starting something else?

One or two specific comments on your principles:

> POLS
> ====
> 
> means that a subject should be able to know the outcome of an operation
> it has explicitly triggered.

This is not possible in principle, for several reasons:

  1. I could start a computation that fails
  2. I might start a computation by sending a one-way message.
     For this message there may be no reply.
  3. It violates some security policies.

However, I suspect that none of these are an issue in practice. Can you
expand what you are trying to get to here so that we can identify the
right principle and capture it?

> EE
> ==
> 
> means that the design should include points where user can select the
> service to implement an interface and also provide means of composition
> to easily build services on top of the existing ones.
> 
> Examples
> --------
> 
> Extensibility: the TCP/IP stack need not be a mandatory system
> component, even if a default one is provided for convenience.

Yes. The only components that need to be mandatory are those that guard
the boundary between one user and another. For example, drivers that can
perform DMA.

> KISS
> ====
> 
> means that the design should be kept easy to understand and implement.
> It makes it less likely that bugs creep in the system, as it is easier
> to verify specification and implementation.

I agree with the intention, but there are some caveats:

There are places in any system that may be simple but not easy to
understand. The strange reductio between SpaceBank, MetaConstructor, and
PCC in EROS is one example. It is very simple from an implementation
perspective, but a bit confusing from the human perspective.

I think that both simplicities are desirable, but if I have to choose
between one and the other, then at lower levels of the system I choose
implementation simplicity. Most users do not see these levels in any
case.

> EUR
> ===
> 
> means that requirements of the system should be kept as small as
> possible, to keep resources available to user applications and enable
> use in limited environents (e.g. great number of users, high workload or
> embedded hardware).

... or the system should admit of multiple implementations, *some* of
which have this property.

Perhaps you mean to say "the *minimum* requirements"?


And how about two more:


Principle of Authorized Communication

An entity A should only be able to send messages to an entity B if it
can demonstrate the authority to do so.

Explicit Designation of Authority

When an entity wields an authority, it must *explicitly* designate the
source of the authority.

  Examples:  The UNIX read() call explicitly designates its
             file descriptor, but the UNIX open() call fails this
             test, because it does not explicitly designate its
             authority to perform opens.

Another way to state this principle is "no ambient authority".


-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100