[e-lang] Fwd: Notes from Jul 10's phone discussion

[Kevin Reid]

Begin forwarded message:

> From: "Mark S. Miller" <markm at caplet.com>
> Date: July 11, 2004 15:33:43 EDT
> To: Kevin Reid <kpreid at attglobal.net>
> Subject: Re: Notes from Jul 10's phone discussion
> X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
>
> At 06:19 PM 7/10/2004  Saturday, Kevin Reid wrote:
>
>> ---- Introducer#sturdyToURI is not CapTP-system-specific
>>
>> I believe you asked to be reminded of this bug report, even though  
>> the bug
>> will be gone once CapTP-in-E is done.
>>
>>> Subject: Re: [e-lang] How do I serialize a SturdyRef?
>>> Date: Fri, 30 Jan 2004 09:54:16 -0500
>>> Message-ID: <1g8d76q.1xhkkx1hg4o9rM%kpreid at attglobal.net>
>> ...
>>> I think I see a bug: assuming SturdyRefs are intended to be specific  
>>> to a given instantiation of the comm system, Introducer.sturdyToURI  
>>> breaks this by amplifying all SturdyRefs regardless of whose  
>>> LocatorUnum they hold.
>
> Thanks. This is now bug
> https://bugs.sieve.net/bugs/? 
> func=detailbug&bug_id=125628&group_id=16380
>
>
>> ---- Mobile code as CapTP option

Context for e-lang readers:

Mobile code is unsafe for persistent vats with valuable state, as not  
only can it

     1. hang the vat, or
     2. prevent serialization of the vat,

it can also

     3. prevent unserialization of the vat's state, after an arbitrary  
number of checkpoint-and-restore cycles.

>> Our discussion concluded that mobile code could be made safe by making
>> acceptance of mobile code a CapTP per-instance option.
>>
>> Systems that wished to accept mobile code would then create an  
>> intermediate
>> vat in which the mobile code for a given client, plus the 'server'  
>> code
>> whose state the system can afford to lose, resides.
>>
>> A further extension which might be useful, but is not necessary,  
>> would be
>> mobile code which is flagged by the receiving CapTP instance as such  
>> and
>> which the persistence system will serialize as a broken reference.  
>> Mobile
>> code can then be used as a "network optimization" - it can do things  
>> without
>> roundtrips, and interact with near objects, but can't persist, and  
>> therefore
>> can't break [un]serialization.
>
> Could you resend this to e-lang? Or give me permission to? Thanks.
>
>
>> ---- Identity object
>>
>> def makeIdentityKey(what) :any {
>>  def identityKey implements Selfless {
>>    to dummyMethod() :void {
>>      __identityFunc(what)
>>    }
>>  }
>>  return identityKey
>> }
>>
>> The identity key object would be used for an auditor in a
>> no-unshadowable-names world to specify, without revealing, the  
>> bindings that
>> it requires to be present at runtime in the scope of the audited  
>> object.
>
> Cool -- I hand't thought that we could write this in E, rather than
> providing it as a primitive.
>
> I think this should read something like:
>
>     def makeIdentityKey(what) :any {
>         def identityKey implements Selfless {
>             to __optSealedDispatch(brand) :void {
>                 def eqSealer := __equalizer.getSealer()
>                 switch (brand) {
>                     match ==(eqSealer.getBrand()) {
>                         return eqSealer.seal([makeIdentityKey, "run",  
> [what]])
>                     }
>                 }
>             }
>         }
>         return identityKey
>     }
>
> in order to make explicable how the __equalizer is able to obtain the  
> info
> to compare, while still having it be hidden from normal clients. (The
> corresponding Unsealer would be hidden inside the __equalizer.)
>
> (If an identityKey is also to be persistent, the same technique would  
> be
> used with the persistence system's Sealer.)
>
> With your permission, I'd like to resend this to e-lang as well, or you
> could. Thanks.
>
>
> -- 
> Text by me above is hereby placed in the public domain
>
>         Cheers,
>         --MarkM
>
>
-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>