At 8:45 -0700 00/06/30, Karp, Alan wrote:
>> -----Original Message-----
>> From: Norman Hardy [mailto:norm@netcom.com]
>> Sent: Thursday, June 29, 2000 6:41 PM
>> To: Karp, Alan; 'e-lang@eros-os.org'
>> Subject: RE: Split Capabilities: Making Capabilities Scale
>>
>> (snip)
>>
>> Capabilities are a bit like floating point values. You do not
>> need enough
>> storage to keep every possible floating point value even
>> though in general
>> a particular computation may in principle use any possible
>> floating point
>> number. As with fp numbers you may discard them and reproduce
>> them upon
>> demand. Most Keykos objects were created and destroyed with
>> few of the
>> possible capabilities for them ever having existed. Many (most?)
>> capabilities were created, passed, used and then discarded in
>> less than a
>> second.
>>
>> Your pattern may have other strengths, however.
>>
>
>Many cryptographically secure capabilities are not lightweight enough to be
>treated so cavalierly. For example, the SPKI certificates used in e-speak
>Beta 3.0 carry quite a bit of information, and delegating a subset of the
>rights is a non-trivial operation. We were quite latency sensitive in the
>early days of e-speak, sub millisecond latency being our goal. I don't
>think that's possible if capability construction is in the critical path.
>
>There is another difference here. Most Keykos objects were transient
>instantiations. Many if not most of the services and resources in e-speak
>are persistent or at least long-lived. Examples include files, SAP, and the
>like. Hence, it is not unlikely that most combinations of access rights
>will be needed over the lifetime of an e-speak resource.
I agree that crypto capabilities are expensive to produce, but that may be
reason to postpone creating them until they are actually needed. Reading
Jonathan's response reminds me that I don't understand you wild card
scheme, which is probably my fault. Also what Johnathan says of
capabilities is true of Keykos in that there are typically only two or
three capabilities possible to a given object, only one of which may ever
be created for that particular object. Each capability will have its own
methods (we called them orders). More esoteric capabilities to some object
are likely invented after the the object's code is frozen and the new
capability is via a front end.
Norman Hardy <http://www.mediacity.com/~norm>