[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.
Quickly,
Pierre
--
address@hidden
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
- Design principles, Pierre THIERRY, 2007/01/14
- Re: Design principles, Jonathan S. Shapiro, 2007/01/14
- Re: Design principles,
Pierre THIERRY <=
- Re: Design principles, olafBuddenhagen, 2007/01/14
- Re: Design principles, Marcus Brinkmann, 2007/01/15
- Re: Design principles, Jonathan S. Shapiro, 2007/01/15
- Re: Design principles, Marcus Brinkmann, 2007/01/15
- Re: Design principles, Jonathan S. Shapiro, 2007/01/15
- Re: Design principles, Marcus Brinkmann, 2007/01/15
- Re: Design principles, Jonathan S. Shapiro, 2007/01/15
- Re: Design principles, Neal H. Walfield, 2007/01/15
- Re: Design principles, Jonathan S. Shapiro, 2007/01/15