On Mon, 2007-01-15 at 03:47 +0100, Pierre THIERRY wrote: > > > 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.
Let me give an example, and try to make my distinction more clear. There are many cases where an operation can be optimized by caching partial results. The operation can be performed successfully with no cache at all, but the cache improves performance. On a memory-limited device, one might choose to accept lower performance in order to eliminate the cache. More generally, there is a fundamental tradeoff between resources consumed and performance in many operations and implementations. So, I would say that there are two kinds of things to minimize here: 1. Architected resources. That is: the specification should involve the least number of conceptual entities that is possible, given the requirements of the system. This is an architectural variant of the "Principle of Least Mechanism" (which is a good principle, IMO). 2. Implementation resources. That is: the implementation should realize the architecture using a level of resource that is ``reasonable'' for the implementation environment, and the architecture should admit implementations that involve minimal implementation 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. Explicit designation is definitely separate from POLA. POLA says I should have as little authority as possible. Explicit Designation says that I should explicitly state exactly what authority I am using when I use it. The Principle of Authorized Communication needs to be re-framed, and is possibly implied by POLA+ExplicitDesignation. The problem with the principle as I stated it is that it admits a trivial realization by authorizing all communications. shap -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC +1 443 927 1719 x5100 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
