[cap-talk] Cap OS question

[Ben Kloosterman]

>On Mon, Aug 03, 2009 at 12:36:21AM +0800, Ben Kloosterman wrote:
>> Unsafe code will be limited eg no user apps will support it . Note CIL
>(
>> bytecode) assemblies with unsafe code on them are marked unsafe and the
>OS
>> will compile all bytecode during installation so we can choose note to
>> compile these ( there is also the reference checks) . The other change
>is
>> MetaData/Reflection will be limited eg no support for Emitting code ,
>> reading the underlying bytes or private members.
>
>That all sounds well and good.
>
>> I was thinking of making Capabilies contain a reference ( which is fine
>if
>> they are stored in the kernel)
>
>I think you're misunderstand me; what's wrong with just making a
>capability be a normal object reference? i.e. it sounds as though you're
>proposing to have a "Capability" class and then have methods in this
>class that does invocation.  You've got a nice safe language why not
>exploit it to its full potential?

I was thinking about the rights. 
>
>> but the main issues are
>> 1) Persistence so would need to store a reference that is not a memory
>> address when storing on disk.
>
>What sort of garbage collection are you doing?  If you're doing say a
>copying collector then you must be able to deal with objects moving
>anyway and this should just be able to use the same mechanisms.
>
>> 2) How to handle the access rights and where does the logic go . In the
>> capability ?
>
>Access rights belong in the object the capability points to.

Very interesting .  This basically adds the requirement that each such
object has only set of one access rights.  How do you handle a Process
object  in terms of the Process itself and a separate read only version.
Either 

1) You store multiple requesters ie an ACL
2) You create wrapper objects with the rights and hence you get a Capability
as a ref + access rights.
3) You  go the whole OO way and rely on the language for access rights eg
the read only version is an interface of the object eg an IProcessView. You
are getting in the realm of OO theory though the main difference is you keep
these objects  and interfaces in lists so all access is done through them if
you don't have the reference you can't access it ( eg no statics) . The
reference can't be exposed to the application as he doesn't easily have the
type and can clone it .

3 Sounds very intriguing is it viable ?  Is it a capability OS ? 

Regards, 

Ben