[cap-talk] Fwd: Forward of moderated message

[Charles Landau]

[Note: discussion has moved to cap-talk. Please make sure you reply 
to cap-talk. No need to cross-post to capros-devel.]

>From: Lex Spoon <lex at lexspoon.org>
>To: capros-devel at lists.sourceforge.net
>Subject: Re: [CapROS-devel] Rescind vs. sever
>Date: Wed, 21 Nov 2007 18:45:45 -0500
>User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
>References: <p06230902c36a554ef4cd@[192.168.0.35]>
>	<4744B7BF.4000205 at industrial-designers.co.uk>
>In-Reply-To: <4744B7BF.4000205 at industrial-designers.co.uk>
>MIME-Version: 1.0
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>Message-Id: <200711211845.46706.lex at lexspoon.org>
>
>On Wednesday 21 November 2007 17:57:03 David Hopwood wrote:
>>  I don't know KeyKOS well enough to say whether there were compelling
>>  uses in that context; in general 'Sever' doesn't seem all that useful
>>  (no object language that I know of has a similar operation, although
>>  most have a convention of providing 'clone' for almost all objects).
>
>
>Just to state what might be obvious, 'sever' sounds to me like a
>simplified 'revoke' revoke the revocation pattern.  After calling
>sever/revoke, you know that anyone you passed the reference can no longer use
>their old reference.  So the presence of 'sever' means you can always revoke
>a reference, even if you did not set up a revoker ahead of time.
>
>I have not delved into such systems enough to say whether you want this to
>always be available on every reference.  One issue is that it is a really
>simplified instance of the revocation pattern, so many users of the
>revocation pattern will not be able to use this primitive.  On the other
>hand, it looks convenient in times where it is easier to track the known-good
>referencers of an object than it is to track the revokers for each copy that
>was given out.
>
>An additional use would seem to be to help with an issue I've long wondered
>about with the programmer's shell.  If you are a programmer monkeying with
>your system, then you will sometimes write incorrect code.  I know, I know,
>none of the present company, but some programmers do write incorrect code
>sometimes.  In such a case, it would seem nice if the shell gave you some
>sort of revocation available on all of the objects "owned" by that
>programmer, so that they can get the system back into a sane state with no
>leaked references.  For example, if you have been editing the password file,
>and now you are done, wouldn't it be nice to do some kind of revocation to
>make sure that only the three known-good places that are supposed to have
>this reference still do?
>
>In such cases, Sever is not exactly what you want, but it would enable the
>shell to help you out.  The shell would let you specify which referencers
>should be allowed to hold onto their references.  The shell would then call
>sever, and update only those referencers that you designate with the newly
>created reference to the object.  Sturdy references usable from outside the
>machine, if any exist, would all get disabled.
>
>
>Lex