[cap-talk] Objects and Facets

[Norman Hardy]

I grant the following points made in the mail below (and previously).

In the context of David's description of the up-down counter,  
"component" makes sense as a noun for what I would call an object.
It becomes a component of the app that calls the counter creator.

In my model with several facets to the same object I must explain how  
the implementation of such an object distinguishes via which facet a  
message arrived. This is unnecessary in your model.

In our descriptions of specific functionalities, we need a name for  
the site of the state.
You would say 'component', I would say 'object'. I grant that  
'component' suits the case at hand.
We may or may not need a name for the unique thing designated by a  
capability.
In your adequate description of the counter below, you could have  
said that 3 capabilities were returned.
Then 'facet' would be unneeded. I don't know whether you can  
generally avoid the term.
Both of our descriptions need additionally to specify that the three  
returned capabilities provide the only access to the state.
(I would bundle such security requirements with the specifications.)
I don't know whether some style of description can cover this  
implicitly.

We both abuse terminology when we say 'increment an integer' but that  
is not germane to the current issue.


On Aug 8, 2006, at 4:57 AM, David Hopwood wrote:

> Norman Hardy wrote:
>> I think we need to talk about two different languages here.
>> One language is used to document specific functionalities provided by
>> a bodies of code residing within a capability system.
>> The other is to describe models of capability systems.
>>
>> When I implement an up-down counter I want to document it as follows:
>>
>> An up-down counter is an object whose mutable state is a 64 bit  
>> integer.
>> Calling the UDCC creates a counter and returns three facets thereto:
>> Up, Down and Read.
>> Invoking Up increments the integer, Invoking Down decrements the
>> integer. Read returns the integer.
>> The counter's initial integer is 0.
>>
>> It seems clear to me that on the user side of this abstraction
>> boundary there is just one object and three facets, regardless of the
>> technology I use to create those three keys.
>
> I disagree. The only problem here is that you are using different
> terminology to the object capability model. Using the latter  
> terminology,
> the counter would be documented like this:
>
>   An up-down counter is an component whose mutable state is a 64  
> bit integer.
>   Calling the counter-maker creates a counter and returns three  
> facets which
>   are functions: Up, Down and Read.
>   Invoking Up() increments the integer, Invoking Down() decrements the
>   integer. Read() returns the integer.
>   The counter's initial integer is 0.
>
>> The keys may be all to the same domain or to three domains or indeed
>> one domain may implement several counters.
>
> The object-cap-model terminology is also neutral with respect to these
> implementation details (for systems that have domains separate from  
> objects).
>
>> In any case three keys are facets to the same object.
>
> The three keys are facets (= external objects) to the same  
> component, not
> object.
>
> -- 
> David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk