Re: Summary of copy-on-write

[Guenter Kniesel <Guenter.Kniesel@Informatik.Uni-Bonn.DE>]

    > Also, have you considered any ways to simplify all those permissions?
    > Or perhaps they are simple enough already?

I think they _cann't_ be simplified in the sense that no subset can offer the
same functionality. They surely _can_ be simplified by omitting some features,
e.g. one could argue that copy-on-read isn't really needed. 

Delegation expresses the dependency of one object of another one. The different 
"copy-..." permissions are not only a way to protect the parent object but 
also a means of controlling how long this dependency will last. The "default"
functionality of copy-slots is just a side-effect.
The options of "copy-immediate", "copy-on-{read,write}" and "write access" 
give meaningfull alternatives for "cutting the umbilical cord" between 
a parent and a child, ranging from immediate cutting to never cutting. 
Currently I cann't estimate how often applications really need each of 
these possibilities.


    > Are they powerful enough to describe all the access restrictions and
    > permissions you might want?
    > (Don't you need something like "friends"?)
     
Thanks for your suggestion. I didn't consider friends yet, mainly because I'm currently 
thinking more about a general model not a special language. A full fledged language 
implementing the model might add some useful features like, for instance, friends. 

Since Bill Burdick's "secure slots" correspond to the --xw permission 
(no external access but xw access via delegation) 
his proposal for friendly behaviour using dynamic inheritance would also apply:

   > Using dynamic inheritence, you can make a 'probe' object that will allow 
   > access to secure slots.  You can use these probes to implement friendly 
   > behavior (sorry for the pun).
   
I don't know whether using dynamic inheritance would really be more efficient 
then doing it without friends. 
What I consider more important in his comment is the fact that "--" protection 
at the external interface level can be circumvented by temporarily delegating 
to an object (hence aquiring the possibly less restrictive permissions at the
delegation interface level). This is an argument _against_ any proposal for
making the delegation interface more permissive then the external interface! 


Guenter