[e-cvs] cvs commit: e/doc/elib/capability/ode index.html ode-ack.html ode-bearer.html ode-capabilities.html ode-game.html ode-linear.html ode-objects.html ode-pki.html ode-protocol.html ode-references.html ode-submission.html ode-uber.html overview.html
Mark Miller
markm@eros.cs.jhu.edu
Mon, 25 Feb 2002 10:11:10 -0500
markm 02/02/25 10:11:09
Modified: doc/elib/capability/ode index.html ode-ack.html
ode-bearer.html ode-capabilities.html ode-game.html
ode-linear.html ode-objects.html ode-pki.html
ode-protocol.html ode-references.html
ode-submission.html ode-uber.html overview.html
Log:
finally checking in again
Revision Changes Path
1.58 +2 -2 e/doc/elib/capability/ode/index.html
Index: index.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/index.html,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- index.html 15 Nov 2001 05:08:01 -0000 1.57
+++ index.html 25 Feb 2002 15:11:09 -0000 1.58
@@ -112,8 +112,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.20 +2 -2 e/doc/elib/capability/ode/ode-ack.html
Index: ode-ack.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-ack.html,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- ode-ack.html 15 Nov 2001 05:08:01 -0000 1.19
+++ ode-ack.html 25 Feb 2002 15:11:09 -0000 1.20
@@ -102,8 +102,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.46 +23 -17 e/doc/elib/capability/ode/ode-bearer.html
Index: ode-bearer.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-bearer.html,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- ode-bearer.html 15 Nov 2001 05:08:01 -0000 1.45
+++ ode-bearer.html 25 Feb 2002 15:11:09 -0000 1.46
@@ -260,18 +260,20 @@
<h2><a name="options-contract"></a>An Options Smart Contract</h2>
<p>
<blockquote>
- <pre>def CoveredCallOptionMaker(timer, <font face="Times New Roman, Times, serif"># access to a real-world time service</font>
+ <pre># E sample
+
+def CoveredCallOptionMaker(timer, <font face="Times New Roman, Times, serif"># access to a real-world time service</font>
escrowedStock, <font face="Times New Roman, Times, serif"># reserves stock while offer is OPEN</font>
- escrowedMoney <font face="Times New Roman, Times, serif"># intermediate money-transfer purse
+ escrowedMoney, <font face="Times New Roman, Times, serif"># intermediate money-transfer purse
</font> <font face="Times New Roman, Times, serif"># The 3 args above are from broker. The 4 below from options-writer</font>
stockSrc, <font face="Times New Roman, Times, serif"># provides the stock offered for sale</font>
deadline :integer, <font face="Times New Roman, Times, serif"># time until which the offer is OPEN</font>
moneyDest, <font face="Times New Roman, Times, serif"># where the seller receives payment</font>
- exercisePrice :integer) <font face="Times New Roman, Times, serif"># the price that must be paid for the stock</font>
-:any {
+ exercisePrice :integer <font face="Times New Roman, Times, serif"># the price that must be paid for the stock</font>
+) :any {
def numShares :integer := stockSrc getBalance() <font face="Times New Roman, Times, serif"># how many shares are offered
</font> escrowedStock deposit(numShares, stockSrc) <font face="Times New Roman, Times, serif"># escrow all the shares in stockSrc</font>
- def state := "OPEN" <font face="Times New Roman, Times, serif"># one of OPEN, CLOSED, or CANCELLED</font>
+ var state := "OPEN" <font face="Times New Roman, Times, serif"># one of OPEN, CLOSED, or CANCELLED</font>
def cancel() {
if (state == "OPEN") {
@@ -280,7 +282,7 @@
}
}
timer after(deadline - timer now(), cancel) <font face="Times New Roman, Times, serif"># after the deadline passes, call cancel()
-</font>
+</font>
def CoveredCallOption {
to printOn(out) {
if (state == "OPEN") {
@@ -295,11 +297,11 @@
to getNumShares() :any { numShares }
to getExercisePrice() :any { exercisePrice }
to getDeadline() :any { deadline }
-
+
to exercise(moneySrc, stockDest) {
- require(state == "OPEN", _{"not open"}) <font face="Times New Roman, Times, serif"># throws "not open" if test fails</font>
- require(timer now() < deadline, _{"too late"})
-
+ require(state == "OPEN", thunk{"not open"}) <font face="Times New Roman, Times, serif"># throws "not open" if test fails</font>
+ require(timer now() < deadline, thunk{"too late"})
+
escrowedMoney deposit(exercisePrice, moneySrc)
<font face="Times New Roman, Times, serif"># only if the call-writer can be properly paid do we proceed
</font> state := "CLOSED"
@@ -396,12 +398,16 @@
object:</p>
<p>
<blockquote>
- <pre>def TitleCompanyMaker(precious, name) :any {
- require(precious != null, _{"must provide an object"})
+ <pre># E sample
+
+def BrandMaker := <import:org.erights.e.elib.sealing.Brand>
+
+def TitleCompanyMaker(precious, name) :any {
+ require(precious != null, thunk{"must provide an object"})
def [sealer, unsealer] := BrandMaker pair(name)
- def PurseMaker(myPrecious) :any {
+ def PurseMaker(var myPrecious) :any {
def extract() :any {
- require(myPrecious != null, _{"empty"})
+ require(myPrecious != null, thunk{"empty"})
def result := myPrecious
myPrecious := null
result
@@ -412,7 +418,7 @@
to sprout() :any { PurseMaker(null) }
to getExtract() :any { sealer seal(extract) }
to deposit(src) {
- require(myPrecious == null, _{"full"})
+ require(myPrecious == null, thunk{"full"})
myPrecious := unsealer unseal(src getExtract())()
}
to exercise(verb, args) :any {
@@ -523,8 +529,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.45 +64 -41 e/doc/elib/capability/ode/ode-capabilities.html
Index: ode-capabilities.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-capabilities.html,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- ode-capabilities.html 15 Nov 2001 05:08:01 -0000 1.44
+++ ode-capabilities.html 25 Feb 2002 15:11:09 -0000 1.45
@@ -194,15 +194,18 @@
such a pair. When the sealer is asked to seal an object it returns an
envelope which can only be unsealed by the corresponding unsealer.
<p>
- <blockquote>
- <pre><b>? </b><i>def [sealer, unsealer] := BrandMaker pair("MarkM")</i>
+ <blockquote>
+ <pre><b>? </b><i>def BrandMaker := <import:org.erights.e.elib.sealing.Brand>
+</i><b># value: <import:org.erights.e.elib.sealing.Brand>
+
+? </b><i>def [sealer, unsealer] := BrandMaker pair("MarkM")</i>
<b># value: [<MarkM sealer>, <MarkM unsealer>]
-
-? </b><i>def envelope := sealer seal("Tuna")</i>
+
+</b><b>? </b><i>def envelope := sealer seal("Tuna")</i>
<b># value: <sealed by MarkM>
-
+
? </b><i>unsealer unseal(envelope)</i>
-<b># value: Tuna</b></pre>
+<b># value: "Tuna"</b></pre>
</blockquote>
<p>If the envelope is the can and the unsealer is the can-opener (specific
to this brand of cans), then <code>Tuna</code> is the food. <i>(The name-string
@@ -239,12 +242,14 @@
<code>purse</code>s of the same currency, you can <code>deposit</code>
money into one from the other.
<blockquote>
- <pre>def <b>MintMaker</b>(name) :any {
+ <pre># E sample
+
+def <b>MintMaker</b>(name) :any {
def [sealer, unsealer] := BrandMaker pair(name)
def mint {
to printOn(out) { out print(`<$name's mint>`) }
-
- to makePurse(balance :(integer >= 0)) :any { <font face="Times New Roman, Times, serif">#See <a href="#integer-note">Note below</a></font>
+
+ to makePurse(var balance :(integer >= 0)) :any { <font face="Times New Roman, Times, serif">#See <a href="#integer-note">Note below</a></font>
def <b>decr</b>(amount :(0..balance)) {
balance -= amount
}
@@ -253,7 +258,7 @@
to getBalance() :any { balance }
to sprout() :any { mint makePurse(0) }
to getDecr() :any { sealer <b>seal</b>(decr) }
-
+
to <b>deposit</b>(amount :integer, src) {
unsealer <b>unseal</b>(src getDecr())(amount)
balance += amount
@@ -265,13 +270,8 @@
</blockquote>
<p><i>(The "<tt>name</tt>" variable and the "<tt>printOn</tt>" methods illustrate
no security properties. They exist purely for debugging purposes.) </i></p>
- <p><i><a name="integer-note"></a>Note: The proper form of the expression
- </i>"<code>(integer >= 0)</code>"<i> depends on the version
- of E. In E <= 0.8.9, this is written as </i>"<code>(_ >= 0)</code>"<i>.
- In E > 0.8.9 & E < 0.8.10, this is written as </i>"<code>(any
- >= 0)</code>"<i>. In E >= 0.8.10, this is written as </i>"<code>(integer
- >= 0)</code>"<i>, as shown above.</i></p>
- <p>This simple piece of code demonstrably has the following security properties
+ <p>This simple piece of code demonstrably has the following security properties
+ </p>
<ol>
<li> Only someone with the mint of a given currency can violate conservation
of that currency.</li>
@@ -283,16 +283,27 @@
<li> A reported successful deposit can be trusted as much as one trusts
the purse one is depositing into.</li>
</ol>
- <p>To understand this, let's walk through how Alice pays Bob $10. We skip
- how we arrive at our initial conditions, where Alice and Bob each have
- a main purse of the same currency, and Alice already has at least $10.
- </p>
- <p>First, playing Alice, we would sprout a new purse from our main purse,
+ <p>To understand this, let's walk through how Alice pays Bob $10. First,
+ let's model our initial conditions, where Alice and Bob each have a main
+ purse of the same currency, and Alice already has at least $10. </p>
+ <blockquote>
+ <pre><b>? </b><i>def CarolMint := MintMaker("Carol")</i><b>
+# value: <Carol's mint>
+
+? </b><i>def AliceMainPurse := CarolMint makePurse(1000)</i><b>
+# value: <has 1000 Carol bucks>
+
+? </b><i>def BobMainPurse := CarolMint makePurse(0)</i><b>
+# value: <has 0 Carol bucks></b></pre>
+ </blockquote>
+ <p>Let's imagine that Carol (the mint owner) sends these purses as arguments
+ in messages to Alice and Bob respectively.</p>
+ <p>First, playing Alice, we would sprout a new purse from our main purse,
and then transfer $10 into it:</p>
<p>
<blockquote>
<pre><b>? </b><i>def paymentForBob := AliceMainPurse sprout()</i>
-<b># value: <has 0 MarkM bucks>
+<b># value: <has 0 Carol bucks>
? </b><i>paymentForBob deposit(10, AliceMainPurse)</i></pre>
</blockquote>
@@ -300,7 +311,7 @@
containing $10 as payment:</p>
<p>
<blockquote>
- <pre><b>? </b><i>bob foo(..., paymentForBob, ...)</i></pre>
+ <pre><i>bob foo(..., paymentForBob, ...)</i></pre>
</blockquote>
<p align="center"><img src="images/mint.gif" width="460" height="334"></p>
<p><i>(Although it may not be obvious, in the above figure the three rightward
@@ -317,21 +328,33 @@
}
}</pre>
</blockquote>
- <p>This last <code>deposit</code> operation is key. Its success assures
- Bob that his main purse has been credited with $10. Under all other conditions
- it must fail. Under <i>all</i> conditions, the integrity of the money
- system must be conserved. All this despite the use of the payment parameter
- which, since it was received from an untrusted source, may be any arbitrary
- object. The <code>deposit</code> method must verify that the <code>src</code>
- purse is a purse of the same currency, and if so, that it has adequate
- funds to cover the transfer. If so it must decrement the <code>src</code>
- purse's <code>balance</code> by this amount and increment its own <code>balance</code>
- by that same amount. The problem? How can we allow the <code>src</code>
- purse to be told to decrement its <code>balance</code> by a sibling purse
- (one of the same currency), but not allow a client of the purse, such
- as Alice, to violate conservation of currency by making the same request?
- Conversely, how can we prevent Alice from providing a bogus purse that
- claims it has decremented itself, only to fool Bob's purse into incrementing
+ So playing Bob, we perform
+ <blockquote>
+ <pre><b>? </b><i>BobMainPurse deposit(10, paymentForBob)</i></pre>
+ </blockquote>
+ <p>Our new balances are</p>
+ <blockquote>
+ <pre><b>? </b><i>BobMainPurse getBalance()</i><b>
+# value: 10
+
+? </b><i>AliceMainPurse getBalance()</i><b>
+# value: 990</b></pre>
+ </blockquote>
+ <p>This last <code>deposit</code> operation is key. Its success assures
+ Bob that his main purse has been credited with $10. Under all other conditions
+ it must fail. Under <i>all</i> conditions, the integrity of the money
+ system must be conserved. All this despite the use of the payment parameter
+ which, since it was received from an untrusted source, may be any arbitrary
+ object. The <code>deposit</code> method must verify that the <code>src</code>
+ purse is a purse of the same currency, and if so, that it has adequate
+ funds to cover the transfer. If so it must decrement the <code>src</code>
+ purse's <code>balance</code> by this amount and increment its own <code>balance</code>
+ by that same amount. The problem? How can we allow the <code>src</code>
+ purse to be told to decrement its <code>balance</code> by a sibling purse
+ (one of the same currency), but not allow a client of the purse, such
+ as Alice, to violate conservation of currency by making the same request?
+ Conversely, how can we prevent Alice from providing a bogus purse that
+ claims it has decremented itself, only to fool Bob's purse into incrementing
itself at no cost to Alice?</p>
<p>In the <code>deposit</code> method, the payment is bound to the <code>src</code>
parameter and the following body is executed:</p>
@@ -425,8 +448,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.20 +2 -2 e/doc/elib/capability/ode/ode-game.html
Index: ode-game.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-game.html,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- ode-game.html 15 Nov 2001 05:08:01 -0000 1.19
+++ ode-game.html 25 Feb 2002 15:11:09 -0000 1.20
@@ -97,8 +97,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.37 +1 -1 e/doc/elib/capability/ode/ode-linear.html
Index: ode-linear.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-linear.html,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- ode-linear.html 17 Apr 2001 23:08:28 -0000 1.36
+++ ode-linear.html 25 Feb 2002 15:11:09 -0000 1.37
@@ -1669,7 +1669,7 @@
</p>
<p><a name="Szabo97"></a>[Szabo97] Nick Szabo, "<b>Formalizing and
Securing Relationships on Public Networks</b>", First Monday, vol
- 2 no 9, updated copy at <a href="http://www.best.com/%7Eszabo/formalize.html">http://www.best.com/~szabo/formalize.html</a>
+ 2 no 9, updated copy at <a href="http://szabo.best.vwh.net/formalize.html">http://szabo.best.vwh.net/formalize.html</a>
</p>
<p><a name="Tanenbaum86"></a>[Tanenbaum86] Andrew S. Tanenbaum, Sape J.
Mullender, Robbert van Renesse, "<b>Using Sparse Capabilities in
1.39 +216 -182 e/doc/elib/capability/ode/ode-objects.html
Index: ode-objects.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-objects.html,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- ode-objects.html 15 Nov 2001 05:08:01 -0000 1.38
+++ ode-objects.html 25 Feb 2002 15:11:09 -0000 1.39
@@ -47,84 +47,90 @@
</TR>
</TABLE>
<hr>
- <!-- #BeginEditable "LongBody" -->
- <p>Object computation can be understood as the sum of three elements [<a href="ode-references.html#Goldberg76">Goldberg76</a>]
+ <!-- #BeginEditable "LongBody" -->
+ <p>Object computation can be understood as the sum of three elements [<a href="ode-references.html#Goldberg76">Goldberg76</a>]
[<a href="ode-references.html#Hewitt73">Hewitt73</a>]: </p>
- <div align="center">
- <p align="center"><b>Objects == Lambda Abstraction + Message Dispatch
+ <div align="center">
+ <p align="center"><b>Objects == Lambda Abstraction + Message Dispatch
+ Local Side Effects </b></p>
</div>
- <p align="left">(footnote: The remaining feature often thought to be defining
- of object-oriented programming is inheritance. Though we do not view inheritance
- as as a fundamental ingredient of object computation, its widespread use
- in object-oriented programming practice motivates its inclusion in E.
- However, E's reconciliation of inheritance with capability security principles
- [<a href="ode-references.html#Miller99">Miller99</a>] is beyond the scope
+ <p align="left">(footnote: The remaining feature often thought to be defining
+ of object-oriented programming is inheritance. Though we do not view inheritance
+ as as a fundamental ingredient of object computation, its widespread use
+ in object-oriented programming practice motivates its inclusion in E.
+ However, E's reconciliation of inheritance with capability security principles
+ [<a href="ode-references.html#Miller99">Miller99</a>] is beyond the scope
of this paper.) </p>
<h2 align="left"><a name="lambda"></a>Lambda Abstraction</h2>
- <p align="left">Lambda abstraction [<a href="ode-references.html#Church41">Church41</a>]
- is a pure theory of nested function definition and application. In E notation,
- conventional function definition and application should look familiar:
- <p align="left">
- <blockquote>
- <pre>def factorial(n) :any {
+ <p align="left">Lambda abstraction [<a href="ode-references.html#Church41">Church41</a>]
+ is a pure theory of nested function definition and application. In E notation,
+ conventional function definition and application should look familiar:
+ <p align="left">
+ <blockquote>
+ <pre># E sample
+
+def factorial(n) :any {
if (n <= 0) {
1
} else {
n * factorial(n-1)
}
}
-
+</pre>
+ <pre>
<b>? </b><i>factorial(3)</i>
<b># value: 6</b></pre>
</blockquote>
- The only unfamiliar element is the use of "<code>:any</code>"
- rather than an explicit return statement. Like Lisp and Smalltalk, E is
- an expression language -- the value of a block of expressions is the value
- of the last expression in that block. This value is filtered through the
- optional <i>returns type declaration</i>. "<code>:any</code>"
- allows any value to be returned. If no return type is declared, then null
- is returned. <font color="#CC0000">(*** This detail comes too early. Must
- move into a footnote or something.) </font>
- <p>Nested function definition, familiar from all lexical lambda languages
+ The only unfamiliar element is the use of "<code>:any</code>"
+ rather than an explicit return statement. Like Lisp and Smalltalk, E is
+ an expression language -- the value of a block of expressions is the value
+ of the last expression in that block. This value is filtered through the
+ optional <i>returns type declaration</i>. "<code>:any</code>"
+ allows any value to be returned. If no return type is declared, then null
+ is returned. <font color="#CC0000">(*** This detail comes too early. Must
+ move into a footnote or something.) </font>
+ <p>Nested function definition, familiar from all lexical lambda languages
including ALGOL60, Scheme, and ML, should also look familiar:</p>
- <p align="left">
- <blockquote>
- <pre>def adderCreator(x) :any {
+ <p align="left">
+ <blockquote>
+ <pre># E sample
+
+def adderCreator(x) :any {
def adder(y) :any {
x + y
}
}
-
+</pre>
+ <pre>
<b>? </b><i>def addThree := adderCreator(3)
</i><b># value: <adder>
-
+
? </b><i>addThree(5)
</i><b># value: 8</b></pre>
</blockquote>
- <p align="left">The call to <code>adderCreator</code> returns a version
- of the <code>adder</code> function that adds <code>3</code> to its argument.
- Church originally thought about this as substitution -- return an <code>adder</code>
- function in which <code>x</code> has been replaced by <code>3</code>.
- Unfortunately, this simple perspective generalizes poorly. An alternative
- perspective is to consider a function, such as that held in the <code>addThree</code>
- variable, to be a combination of a <i>behavior</i> -- the static code
- for adder, and <i>state</i> -- the runtime bindings for its <i>free</i>
- variables. <code>x</code> in <code>adder</code> is a free variable in
- that <code>adder</code> uses <code>x</code>, but the corresponding definition
- of <code>x</code> is inherited from <code>adder</code>'s creating context.
- In the remainder of this paper, we will refer to such free state variables
- as <i>instance variables</i>.
- <p align="left">Such functions already have the most often cited attribute
- of objects: they are a combination of encapsulated state together with
- behavior that has exclusive access to that state. Ignoring for a moment
- the message-name <code>foo</code>, the Granovetter Diagram describes an
- important aspect of the lambda calculus. Imagine that Alice, Bob, and
- Carol are three functions. If, in the initial conditions, Alice contains
- a binding for Bob and Carol, then Alice's behavior can give Bob access
- to Carol.
- <p align="left">
- <blockquote>
+ <p align="left">The call to <code>adderCreator</code> returns a version
+ of the <code>adder</code> function that adds <code>3</code> to its argument.
+ Church originally thought about this as substitution -- return an <code>adder</code>
+ function in which <code>x</code> has been replaced by <code>3</code>.
+ Unfortunately, this simple perspective generalizes poorly. An alternative
+ perspective is to consider a function, such as that held in the <code>addThree</code>
+ variable, to be a combination of a <i>behavior</i> -- the static code
+ for adder, and <i>state</i> -- the runtime bindings for its <i>free</i>
+ variables. <code>x</code> in <code>adder</code> is a free variable in
+ that <code>adder</code> uses <code>x</code>, but the corresponding definition
+ of <code>x</code> is inherited from <code>adder</code>'s creating context.
+ In the remainder of this paper, we will refer to such free state variables
+ as <i>instance variables</i>.
+ <p align="left">Such functions already have the most often cited attribute
+ of objects: they are a combination of encapsulated state together with
+ behavior that has exclusive access to that state. Ignoring for a moment
+ the message-name <code>foo</code>, the Granovetter Diagram describes an
+ important aspect of the lambda calculus. Imagine that Alice, Bob, and
+ Carol are three functions. If, in the initial conditions, Alice contains
+ a binding for Bob and Carol, then Alice's behavior can give Bob access
+ to Carol.
+ <p align="left">
+ <blockquote>
<pre>def ... { <font face="Times New Roman, Times, serif"># enclosing context</font>
def bob := ... <font face="Times New Roman, Times, serif"># instance variable </font>bob<font face="Times New Roman, Times, serif"> somehow bound to Bob</font>
def carol := ... <font face="Times New Roman, Times, serif"># instance variable </font>carol<font face="Times New Roman, Times, serif"> somehow bound to Carol</font>
@@ -135,19 +141,21 @@
}</pre>
</blockquote>
<h2 align="left"><a name="dispatch"></a>Adding Message Dispatch</h2>
- <p>The most visible difference between a function and an object is that
- a function's behavior is written to satisfy just one kind of request,
- and all calls on that function are forms of that one request. By contrast,
- an object's behavior enables it to satisfy a variety of different requests
- (each with a separate <i>method</i>). A request to an object (a <i>message</i>)
- identifies which of these requests is being made. There is nothing fundamental
- here; objects have been trivially built from functions, and vice-versa,
- many times in the history of computer science. In E, behaviors-as-bundles-of-methods
- and requests-as-messages are the more primitive notions, of which functions
+ <p>The most visible difference between a function and an object is that
+ a function's behavior is written to satisfy just one kind of request,
+ and all calls on that function are forms of that one request. By contrast,
+ an object's behavior enables it to satisfy a variety of different requests
+ (each with a separate <i>method</i>). A request to an object (a <i>message</i>)
+ identifies which of these requests is being made. There is nothing fundamental
+ here; objects have been trivially built from functions, and vice-versa,
+ many times in the history of computer science. In E, behaviors-as-bundles-of-methods
+ and requests-as-messages are the more primitive notions, of which functions
are a degenerate case.</p>
- <p>
- <blockquote>
- <pre>def PointMaker(x,y) :any {
+ <p>
+ <blockquote>
+ <pre># E sample
+
+def PointMaker(x,y) :any {
def Point {
to printOn(out) { out print(`<$x,$y>`) }
to getX() :any { x }
@@ -157,66 +165,67 @@
}
}
}
-
+</pre>
+ <pre>
<b>? </b><i>def p := PointMaker(3,5)</i>
-<b># value: <3,5>
-
+<b># value: <3,5>
+
? </b><i>p getX()</i>
<b># value: 3
-
+
? </b><i>p + PointMaker(4,8)
-</i><b># value: <7,13></b></pre>
+</i><b># value: <7,13></b></pre>
</blockquote>
- <p>From a lambda-calculus perspective, <code>PointMaker</code> is like <code>adderCreator</code>
- -- it is a lexically enclosing function that defines the variable bindings
- used by the object it both defines and returns. From an object perspective,
- <code>PointMaker</code> is simultaneously like a class and constructor
- -- both defining the instance variables for <code>Point</code>s, and creating,
- initializing, and returning individual <code>Point</code>s. We have found
- such lambda-based object definition to be simpler, more expressive, and
- more intuitive, than either of the common choices -- class-based and prototype-based
- object definition. The lambda-based technique for defining objects dates
- back at least to 1973 [<a href="ode-references.html#Hewitt73">Hewitt73</a>],
- so we find it distressing that the other two are often assumed to be the
+ <p>From a lambda-calculus perspective, <code>PointMaker</code> is like <code>adderCreator</code>
+ -- it is a lexically enclosing function that defines the variable bindings
+ used by the object it both defines and returns. From an object perspective,
+ <code>PointMaker</code> is simultaneously like a class and constructor
+ -- both defining the instance variables for <code>Point</code>s, and creating,
+ initializing, and returning individual <code>Point</code>s. We have found
+ such lambda-based object definition to be simpler, more expressive, and
+ more intuitive, than either of the common choices -- class-based and prototype-based
+ object definition. The lambda-based technique for defining objects dates
+ back at least to 1973 [<a href="ode-references.html#Hewitt73">Hewitt73</a>],
+ so we find it distressing that the other two are often assumed to be the
only available choices.</p>
- <p>The returned <code>Point</code>s are clearly object-like rather than
- function-like. Each <code>Point</code>'s behavior contains four methods
- -- <code>printOn</code>, <code>getX</code>, <code>getY</code>, and <code>add</code>
- -- and every request to a <code>Point</code> starts by naming which of
- these services is being requested. Now we see that the <code>foo</code>
- in the Granovetter Diagram is simply a message-name. Extending our earlier
+ <p>The returned <code>Point</code>s are clearly object-like rather than
+ function-like. Each <code>Point</code>'s behavior contains four methods
+ -- <code>printOn</code>, <code>getX</code>, <code>getY</code>, and <code>add</code>
+ -- and every request to a <code>Point</code> starts by naming which of
+ these services is being requested. Now we see that the <code>foo</code>
+ in the Granovetter Diagram is simply a message-name. Extending our earlier
example, Alice's behavior would be:</p>
- <p>
- <blockquote>
+ <p>
+ <blockquote>
<pre> bob foo(..., carol, ...)</pre>
</blockquote>
<p>Some shortcuts above need a brief explanation. </p>
- <p>
+ <p>
<ul>
- <li>
+ <li>
<p>"<code>a + b</code>" is merely syntactic shorthand for
"<code>a add(b)</code>", and similarly for other expression
operators. </p>
</li>
- <li>
+ <li>
<p>The command line interpreter prints a value by sending it the <code>printOn</code>
message. </p>
</li>
- <li>
+ <li>
<p>The string between back-quotes and containing $-prefixed expressions
is a quasi-string. Like interpolated strings in Perl, it evaluates
to a string by evaluating the nested expressions and printing them
into the enclosing string. </p>
</li>
- <li>
+ <li>
<p>Finally, functions are simply one-method objects where the method
is named "<code>run</code>". The previous <code>adderCreator</code>
is therefor just syntactic shorthand for:</p>
</li>
</ul>
<p></p>
- <p align="left">
- <blockquote>
+ <p align="left">
+ <blockquote>
<pre>def adderCreator {
to run(x) :any {
def adder {
@@ -228,68 +237,73 @@
}
</pre>
</blockquote>
- <p align="left">
+ <p align="left">
<h2><a name="side-effects"></a>Adding Side Effects</h2>
- <p>Two features of object programming implied by the Granovetter Diagram
+ <p>Two features of object programming implied by the Granovetter Diagram
have been left out of computation as so far described. </p>
- <p>
+ <p>
<ul>
- <li>
- <p>First, the diagram implies that Bob is obtaining access to Carol,
- but computation as so far described gives Bob no means for holding
+ <li>
+ <p>First, the diagram implies that Bob is obtaining access to Carol,
+ but computation as so far described gives Bob no means for holding
on to this access. </p>
</li>
- <li>
- <p>Second, we understand the diagram to say that Alice is giving Bob
- access to Carol herself, not a copy of Carol [<a href="ode-references.html#Deutsch99">Deutsch99</a>].
- However, in computation as has been described so far, Carol is indistinguishable
- from a copy of Carol. We cannot distinguish between pass-by-reference-sharing
- and pass-by-copy, but the Granovetter Diagram clearly intends to show
- specifically pass-by-reference-sharing. Were computation adequately
- described purely in terms of pass-by-copy, the Granovetter Diagram
+ <li>
+ <p>Second, we understand the diagram to say that Alice is giving Bob
+ access to Carol herself, not a copy of Carol [<a href="ode-references.html#Deutsch99">Deutsch99</a>].
+ However, in computation as has been described so far, Carol is indistinguishable
+ from a copy of Carol. We cannot distinguish between pass-by-reference-sharing
+ and pass-by-copy, but the Granovetter Diagram clearly intends to show
+ specifically pass-by-reference-sharing. Were computation adequately
+ described purely in terms of pass-by-copy, the Granovetter Diagram
would be unnecessary. </p>
</li>
</ul>
<p></p>
<p>The introduction of side effects solves both of these problems.</p>
- <p>Starting with lambda calculus (or with lambda plus message dispatch),
- there are many ways to add side effects. The approach used by E, Scheme,
- ML and many other lambda languages is to introduce assignment.</p>
- <p>How does assignment make Carol potentially distinct from a duplicate
+ <p>Starting with lambda calculus (or with lambda plus message dispatch),
+ there are many ways to add side effects. The approach used by E, Scheme,
+ ML and many other lambda languages is to introduce assignment. In E, variables
+ are non-assignable (or "<i><code>final</code></i>") by default.
+ For a variable to be assignable, it must be declared with "<i><code>var</code></i>".</p>
+ <p>How does assignment make Carol potentially distinct from a duplicate
of Carol? Consider:</p>
- <p>
- <blockquote>
- <pre>def CounterMaker() :any {
- def count := 0
+ <p>
+ <blockquote>
+ <pre># E sample
+
+def CounterMaker() :any {
+ var count := 0
def Counter {
to getCount() :any { count }
to incr() { count += 1 }
}
}
-
+</pre>
+ <pre>
<b>? </b><i>def carol := CounterMaker()
-</i><b># value: <counter>
-
+</i><b># value: <Counter>
+
? </b><i>carol getCount()
</i><b># value: 0
-
+
? </b><i>carol incr()
</i><b>
? </b><i>carol getCount()
</i><b># value: 1</b></pre>
</blockquote>
- <p>Two otherwise identical <code>Counter</code>s are distinct because they
- have distinct <code>count</code> variables that increment separately.
- All those who have access to the same <code>Counter</code> are able to
- see the side effects of <code>incr</code> messages sent by others who
+ <p>Two otherwise identical <code>Counter</code>s are distinct because they
+ have distinct <code>count</code> variables that increment separately.
+ All those who have access to the same <code>Counter</code> are able to
+ see the side effects of <code>incr</code> messages sent by others who
have access to this same <code>Counter</code>.</p>
- <p>How does assignment enable Bob to retain access he has been given to
- Carol? By assigning an incoming message-argument to an<code></code> instance
+ <p>How does assignment enable Bob to retain access he has been given to
+ Carol? By assigning an incoming message-argument to an<code></code> instance
variable:</p>
- <p>
- <blockquote>
+ <p>
+ <blockquote>
<pre>def BobMaker() :any {
- def carol := null
+ var carol := null
def Bob {
to foo(..., newCarol, ...) {
carol := newCarol
@@ -300,63 +314,83 @@
</blockquote>
<p></p>
<h2><a name="facets"></a>Composites & Facets</h2>
- <p>Technically, by introducing assignment, we have made each variable into
- a distinct primitive variable-object. A user-defined object then contains
- bindings from the names of these variables to these variable-objects.
- The variable-objects in turn contain the bindings to the current values
- of the variables. When the programmer writes a use-occurrence of the variable
- in an expression, this causes the containing object to send a <code>getValue</code>
- message to the variable-object to get its current value. When the programmer
- writes an assignment, this causes the containing object to send a <code>setValue</code>
- message to the variable-object.</p>
- <p>When a variable is only in the scope of one object, as in all the above
- examples, we usually ignore this distinction, and speak as if the containing
- object has bindings directly from the variable names to the current values
+ <p>Technically, by introducing assignment, we have made each assignable
+ variable into a distinct primitive variable-object, referred to as a <code><i>Slot</i></code>.
+ A user-defined object then contains bindings from the names of these variables
+ to these Slots. The Slots in turn contain the bindings to the current
+ values of the variables. When the programmer writes a use-occurrence of
+ the variable in an expression, this causes the containing object to send
+ a <code>getValue()</code> message to the Slot to get its current value.
+ When the programmer writes an assignment, this causes the containing object
+ to send a <code>setValue(newValue)</code> message to the Slot.</p>
+ <p>When a variable is only in the scope of one object, as in all the above
+ examples, we usually ignore this distinction, and speak as if the containing
+ object has bindings directly from the variable names to the current values
of these variables. But this shortcut does not work for code such as:</p>
- <p>
- <blockquote>
- <pre>def getterSetterPair(value) :any {
- def getter() :any { value }
- def setter(newValue) { value := newValue }
- [getter, setter]
+ <p>
+ <blockquote>
+ <pre># E sample
+
+def incrDecrPair(var value) :any {
+ def incr {
+ to countUp() :any { value += 1 }
+ }
+ def decr {
+ to countDown() :any { value -= 1 }
+ }
+ [incr, decr]
}</pre>
+ <pre><b>? </b><i>def [i, d] := incrDecrPair(3)</i><b>
+# value: [<incr>, <decr>]
+
+? </b><i>i countUp()</i><b>
+# value: 4
+
+? </b><i>i countUp()</i><b>
+# value: 5
+
+? </b><i>d countUp()</i><b>
+# problem: <NoSuchMethodException: <a decr> countUp/0>
+
+? </b><i>d countDown()</i><b>
+# value: 4</b></pre>
</blockquote>
<p></p>
- <p>Each time <code>getterSetterPair</code> is called, it defines a new <code>value</code>
- variable and returns a list of two functions, one that will get the value
- of this variable and one that will set it. This is a trivial example of
- a useful technique -- defining several objects in the same scope, each
- providing different operations for manipulating a common state held in
- that scope. </p>
+ <p>Each time <code>incrDecrPair</code> is called, it defines a new <code>value</code>
+ variable and returns a list of two functions, one that will increment
+ and return the value of this variable and one that will decrement and
+ return it. This is a trivial example of a useful technique -- defining
+ several objects in the same scope, each providing different operations
+ for manipulating a common state held in that scope. </p>
<p align="center"><img src="images/share.gif" width="444" height="131"></p>
- <p>On the left we see, diagrammed in explicit detail, the objects and relationships
- resulting from a call to <code>getterSetterPair</code>. On the right,
- the triple is visualized as a single composite. Like an individual object,
- a composite is a combination of state and behavior. Like an individual
- object, the state consists of all of the variables within the composite.
- The behavior consists of all of the code within the composite, but here
+ <p>On the left we see, diagrammed in explicit detail, the objects and relationships
+ resulting from a call to <code>incrDecrPair</code>. On the right, the
+ triple is visualized as a single composite. Like an individual object,
+ a composite is a combination of state and behavior. Like an individual
+ object, the state consists of all of the variables within the composite.
+ The behavior consists of all of the code within the composite, but here
we have an important difference. </p>
- <p>The behavior elicited by a message to the composite depends not just
- on the message, but, obviously, on which object of the composite receives
- the message. Objects on the surface of the composite -- objects which
- may be referred to from outside the composite, like <code>getter</code>
- and <code>setter</code> -- are <i>facets</i> of the composite. The variable-object,
- <code>value</code>, need not be considered a facet since we can tell that
+ <p>The behavior elicited by a message to the composite depends not just
+ on the message, but, obviously, on which object of the composite receives
+ the message. Objects on the surface of the composite -- objects which
+ may be referred to from outside the composite, like <code>incr</code>
+ and <code>decr</code> -- are <i>facets</i> of the composite. The variable-object,
+ <code>value</code>, need not be considered a facet since we can tell that
no reference to it can escape from the composite.</p>
- <p>The aggregation of a network of objects into a composite is purely subjective
- -- it allows us to hide detail when we wish. The technique works because
- the possible interactions among composites obey the same rules as the
- possible interactions among individual objects -- these rules are therefor
+ <p>The aggregation of a network of objects into a composite is purely subjective
+ -- it allows us to hide detail when we wish. The technique works because
+ the possible interactions among composites obey the same rules as the
+ possible interactions among individual objects -- these rules are therefor
<i>compositional</i>. </p>
<h2><a name="dyna-graph"></a>The Dynamic Reference Graph</h2>
- <p>When speaking of object computation, all too much emphasis is often placed
- on the objects themselves. The fabric of an object system is the dynamic
- reference graph. As suggested by the Granovetter Diagram, objects (or
- composites) are the nodes of this graph and references are the arcs. Only
- computation <i>within</i> the graph brings about changes to the topology
- of the graph (the <i>who refers to whom</i> relationships), and it only
- brings about those changes that are enabled by the graph's current topology.
- To learn the perspective of the Granovetter Diagram is to see the dynamic
+ <p>When speaking of object computation, all too much emphasis is often placed
+ on the objects themselves. The fabric of an object system is the dynamic
+ reference graph. As suggested by the Granovetter Diagram, objects (or
+ composites) are the nodes of this graph and references are the arcs. Only
+ computation <i>within</i> the graph brings about changes to the topology
+ of the graph (the <i>who refers to whom</i> relationships), and it only
+ brings about those changes that are enabled by the graph's current topology.
+ To learn the perspective of the Granovetter Diagram is to see the dynamic
reference graph as primary, and objects themselves as secondary [<a href="ode-references.html#Kay99">Kay99</a>].</p>
<!-- #EndEditable --></TD>
<TD WIDTH="10%"> </TD>
@@ -406,8 +440,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.26 +2 -2 e/doc/elib/capability/ode/ode-pki.html
Index: ode-pki.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-pki.html,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- ode-pki.html 15 Nov 2001 05:08:01 -0000 1.25
+++ ode-pki.html 25 Feb 2002 15:11:09 -0000 1.26
@@ -155,8 +155,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.36 +6 -6 e/doc/elib/capability/ode/ode-protocol.html
Index: ode-protocol.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-protocol.html,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- ode-protocol.html 15 Nov 2001 05:08:01 -0000 1.35
+++ ode-protocol.html 25 Feb 2002 15:11:09 -0000 1.36
@@ -186,15 +186,15 @@
into it:
<p>
<blockquote>
- <pre><b>? </b><i>def paymentForBob := AliceMainPurse sprout()</i>
-<b># value: <has 0 MarkM bucks></b></pre>
+ <pre><i>def paymentForBob := AliceMainPurse sprout()</i>
+<b>value: <has 0 Carol bucks></b></pre>
</blockquote>
<p>This statement causes Alice's vat (VatA) to send a message to the mint's
vat (VatM). The message includes the Swiss number of <code>AliceMainPurse</code>
and the operation <code>sprout</code>. VatM creates a new object as a
result of the message and sends its Swiss number back to Alice.
<blockquote>
- <pre><b>? </b><i>paymentForBob deposit(10, AliceMainPurse)</i></pre>
+ <pre><i>paymentForBob deposit(10, AliceMainPurse)</i></pre>
</blockquote>
<p>VatA sends another message to VatM including the Swiss number of the
newly created <code>paymentForBob</code> purse and the <code>deposit</code>
@@ -205,7 +205,7 @@
containing $10 as payment.
<p>
<blockquote>
- <pre><b>? </b><i>bob foo(..., paymentForBob, ...)</i></pre>
+ <pre><i>bob foo(..., paymentForBob, ...)</i></pre>
</blockquote>
<p>VatA sends a message to Bob's vat (VatB) passing the Swiss number of
the <code>bob</code> object and the operation <code>foo</code>. The parameters
@@ -280,8 +280,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.36 +3 -3 e/doc/elib/capability/ode/ode-references.html
Index: ode-references.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-references.html,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- ode-references.html 15 Nov 2001 05:08:01 -0000 1.35
+++ ode-references.html 25 Feb 2002 15:11:09 -0000 1.36
@@ -163,7 +163,7 @@
</p>
<p><a name="Szabo97"></a>[Szabo97] Nick Szabo, "<b>Formalizing and
Securing Relationships on Public Networks</b>", First Monday, vol
- 2 no 9, updated copy at <a href="http://www.best.com/%7Eszabo/formalize.html">http://www.best.com/~szabo/formalize.html</a>
+ 2 no 9, updated copy at <a href="http://szabo.best.vwh.net/formalize.html">http://szabo.best.vwh.net/formalize.html</a>
</p>
<p><a name="Tanenbaum86"></a>[Tanenbaum86] Andrew S. Tanenbaum, Sape J.
Mullender, Robbert van Renesse, "<b>Using Sparse Capabilities in
@@ -228,8 +228,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.7 +1 -1 e/doc/elib/capability/ode/ode-submission.html
Index: ode-submission.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-submission.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ode-submission.html 30 Apr 2001 20:36:05 -0000 1.6
+++ ode-submission.html 25 Feb 2002 15:11:09 -0000 1.7
@@ -1418,7 +1418,7 @@
University of Pennsylvania, 1999. http://www.cis.upenn.edu/~shap/EROS/thesis.ps
</p>
<p>[Szabo97] Nick Szabo, Formalizing and Securing Relationships on Public Networks,
- First Monday, vol 2 no 9, updated copy at http://www.best.com/~szabo/formalize.html
+ First Monday, vol 2 no 9, updated copy at http://szabo.best.vwh.net/formalize.html
</p>
<p>[Tribble95] E. Dean Tribble, Mark S. Miller, Norm Hardy, Dave Krieger, "Joule:
Distributed Application Foundations", http://www.agorics.com/joule.html, 1995.</p>
1.21 +2 -2 e/doc/elib/capability/ode/ode-uber.html
Index: ode-uber.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/ode-uber.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- ode-uber.html 15 Nov 2001 05:08:01 -0000 1.20
+++ ode-uber.html 25 Feb 2002 15:11:09 -0000 1.21
@@ -172,8 +172,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>
1.6 +2 -2 e/doc/elib/capability/ode/overview.html
Index: overview.html
===================================================================
RCS file: /cvs/e/doc/elib/capability/ode/overview.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- overview.html 15 Nov 2001 05:08:01 -0000 1.5
+++ overview.html 25 Feb 2002 15:11:09 -0000 1.6
@@ -370,8 +370,8 @@
<td>
<div align="right">
<p><a href="http://www.epic.org/crypto/"><img src="../../../images/key.gif" width="37" height="19" alt="Golden Key Campaign" border="0"></a> <a href="http://www.eff.org/br/"><img src="../../../images/ribbon.gif" width="18" height="30"
-alt="Blue Ribbon Campaign" border="0"></a><br>
- <a href="http://www.freesklyarov.org/"><i>Free Dimitry!</i></a></p>
+alt="Blue Ribbon Campaign" border="0"></a>
+
</div>
</td>
</tr>