Re: E patches for review: ELoader, seedVat

On Jun 4, 2010, at 8:38, Thomas Leonard wrote:
> On Mon, 2010-05-24 at 09:50 -0400, Kevin Reid wrote:
> [...]
>> Ah. Your question is not 'how to uncall makeTraceln' but 'how to
>> uncall the loader'. And the answer is to use 'something else'.
>>
>> Since makeELoader gives authority to log with arbitrary prefixes, it
>> should not be exposed: so loader objects, i.e. <this> must not use
>> __optUncall but rather some amplifier.
>>
>> The role to be filled  loader/uncaller pair which gives access to
>> "process authorities" such as makeTraceln and <file> objects,  
>> allowing
>> them to be passed between vats... but shouldn't the usual set,
>> [<unsafe>, <file>, ...] suffice for that? Maybe we need something
>> extensible in that set (i.e. an unsealer amplifier with a public
>> sealer) so that your ELoaders can be uncalled by that?
>
> Is it possible to use sealers with PassByCopy objects? There are a
> number of objects (e.g. <file:...>, ELoaders) that could be pass-by- 
> copy
> over boot-comm (but pass-by-proxy over CapTP) but would need to use
> __optSealedDispatch.

The notion of PassByConstruction is defined in terms of "should this  
behave this way *over the standard CapTP*". PassByCopy is just the  
additional restriction that the object is Selfless such that a  
roundtrip gets you the original object as defined by Equalizer.

There is no reason for these objects not to pass over boot-comm in  
this way: they just won't be formally ordinary-PassByConstruction.

That said, I'm a little uncomfortable with privileging boot-comm here:  
having multiple comm systems creates confusion, and boot-comm was  
intended to be a gimmick for bootstrapping CapTP communication. But I  
don't know offhand what would be better.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>