[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Design principles

From: Pierre THIERRY
Subject: Re: Design principles
Date: Mon, 15 Jan 2007 03:47:45 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Scribit Jonathan S. Shapiro dies 14/01/2007 hora 16:14:
> > 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: [...]
> 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?

I almost wrote "to be defined" because I only have a fuzzy definition of
it in my head.

It's more that a subject should be able to know the possible
side-effects and kind of data returned by an operation.

For example, LaTeX typically disobeys POLS: I never know what kind of
auxiliary files some arbitrary document class or package will produce in
the current directory. It is very problematic to clean a directory from
those files.

> There are places in any system that may be simple but not easy to
> understand. [...]
> 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.

I agree. The obvious reason is that a design esay to implement can
always be thoroughly described to become understandable by humans, where
the contrary is not really possible today AFAIK.

> > 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"?

I'm not sure a different implementation should be needed for different
use cases. It's just that every operation should be able to perform with
a very low minimum of resources.

> 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.

Don't they naturally come from POLA already (though these particular
facets are worth noting). I already mentioned the latter.

OpenPGP 0xD9D50D8A

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]