From Objects To Capabilities
Phil Nicolaļ
philippe.nicolai@ifrance.com
Wed, 21 Mar 2001 15:24:57 +0100
C'est un message de format MIME en plusieurs parties.
------=_NextPart_000_0009_01C0B21B.164BC760
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Capability-based
Financial Instruments=20
http://www.erights.org/elib/capability/ode/index.html
Capability Operating Systems
http://www.erights.org/elib/capability/ode/ode-capabilities.html
The capability was first invented by secure operating system designers. =
It started as a way to protect "primitive" resources such as memory =
segments [Dennis66], but was soon generalized [Wulf74] into a protected =
ability to invoke arbitrary services provided by other processes. For =
each process, there is a table associating small numbers (similar in =
spirit to Unix file descriptors) with the capabilities held by that =
process. These small numbers serve the same function as variable names =
do in the lambda calculus [Rees96]. In a pure capability operating =
system, such as KeyKOS [Hardy85] or EROS [Shapiro99], a process's only =
source of authority is the capabilities that it holds.=20
A capability is normally thought of as a pairing of a designated process =
with a set of services that the process provides. For example, in KeyKOS =
a capability carries a numeric tag which an invoked process receives =
along with an incoming message. The process then typically dispatches to =
a specific method based on both the numeric tag and the KeyKOS =
equivalent of a message name. The equivalence with objects is clear: the =
behavior looked up in this way, paired with the process-state, is the =
same sort of state-and-behavior that defines an object. When different =
capabilities make different behaviors from the same process available =
via different numeric tags, we can view the process as a composite and =
each of its capabilities as a facet
Patterns of Cooperation Without Vulnerability
The capability model is, in a sense, the object model taken to its =
logical extreme. Where object programmers seek modularity -- a decrease =
in the dependencies between separately thought-out units -- capability =
programmers seek security, recognizing that required trust is a form of =
dependency. Object programmers wish to guard against bugs: a bug in =
module A should not propagate to module B. Capability programmers wish =
to guard against malice. However, if B is designed to be invulnerable to =
A's malice, it is likely also invulnerable to A's bugs
http://www.erights.org/elib/capability/ode/ode-capabilities.html
------=_NextPart_000_0009_01C0B21B.164BC760
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000080 face=3DArial =
size=3D2><B>Capability-based<BR>Financial=20
Instruments</B><!-- #EndEditable --> </FONT></DIV>
<DIV><STRONG><FONT color=3D#000080 face=3DArial size=3D2><A=20
href=3D"http://www.erights.org/elib/capability/ode/index.html">http://www=
.erights.org/elib/capability/ode/index.html</A></FONT></STRONG></DIV>
<DIV><FONT color=3D#800080 face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000080 face=3DArial size=3D2>
<H2><A name=3Dcap-os></A>Capability Operating Systems</H2>
<DIV>
<DIV><U><FONT color=3D#800080 face=3DArial size=3D2><A=20
href=3D"http://www.erights.org/elib/capability/ode/ode-capabilities.html"=
>http://www.erights.org/elib/capability/ode/ode-capabilities.html</A></FO=
NT></U></DIV>
<DIV> </DIV></DIV>
<P>The <I>capability</I> was first invented by secure operating system=20
designers. It started as a way to protect "primitive" resources such as =
memory=20
segments [<A=20
href=3D"http://www.erights.org/elib/capability/ode/ode-references.html#De=
nnis66">Dennis66</A>],=20
but was soon generalized [<A=20
href=3D"http://www.erights.org/elib/capability/ode/ode-references.html#Wu=
lf74">Wulf74</A>]=20
into a protected ability to invoke arbitrary services provided by other=20
processes. For each process, there is a table associating small numbers =
(similar=20
in spirit to Unix file descriptors) with the capabilities held by that =
process.=20
These small numbers serve the same function as variable names do in the =
lambda=20
calculus [<A=20
href=3D"http://www.erights.org/elib/capability/ode/ode-references.html#Re=
es96">Rees96</A>].=20
In a pure capability operating system, such as KeyKOS [<A=20
href=3D"http://www.erights.org/elib/capability/ode/ode-references.html#Ha=
rdy85">Hardy85</A>]=20
or EROS [<A=20
href=3D"http://www.erights.org/elib/capability/ode/ode-references.html#Sh=
apiro99">Shapiro99</A>],=20
a process's only source of authority is the capabilities that it holds.=20
<P>A capability is normally thought of as a pairing of a designated =
process with=20
a set of services that the process provides. For example, in KeyKOS a =
capability=20
carries a numeric tag which an invoked process receives along with an =
incoming=20
message. The process then typically dispatches to a specific method =
based on=20
both the numeric tag and the KeyKOS equivalent of a message name. The=20
equivalence with objects is clear: the behavior looked up in this way, =
paired=20
with the process-state, is the same sort of state-and-behavior that =
defines an=20
object. When different capabilities make different behaviors from the =
same=20
process available via different numeric tags, we can view the process as =
a=20
composite and each of its capabilities as a facet</P>
<H2><A name=3Dpatt-coop></A>Patterns of Cooperation Without =
Vulnerability</H2>
<P><FONT size=3D3>The capability model is, in a sense, the object model =
taken to=20
its logical extreme</FONT>. Where object programmers seek modularity -- =
a=20
decrease in the dependencies between separately thought-out units -- =
capability=20
programmers seek security, recognizing that required trust is a form of=20
dependency. Object programmers wish to guard against bugs: a bug in =
module A=20
should not propagate to module B. Capability programmers wish to guard =
against=20
malice. However, if B is designed to be invulnerable to A's malice, it =
is likely=20
also invulnerable to A's bugs</P>
<P><U><FONT color=3D#800080 face=3DArial size=3D2><A=20
href=3D"http://www.erights.org/elib/capability/ode/ode-capabilities.html"=
>http://www.erights.org/elib/capability/ode/ode-capabilities.html</A></FO=
NT></U></P></FONT></DIV></BODY></HTML>
------=_NextPart_000_0009_01C0B21B.164BC760--
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif