[Help-smalltalk] Re: ObjectSpaces

[Gwenaël Casaccio]

Oh I forgot to say we could implement nicely selector namespaces  with that.

On Thu, Oct 21, 2010 at 1:49 PM, Gwenaël Casaccio <address@hidden> wrote:
> Concerning the ObjectSpace model and its interaction with Smalltalk
> I was wondering if we could not be inspired by the microkernel:
>
>  - a service for process management
>  - a service for the classes
>  - a service for security
>  - a service for the filesystem
>  - ...
>
> An advantage of this approach if a service die we could reload it.
> Another point about the OSes and classes, I am not sure if it is
> the nice model but I think that an OS has its own environment (i.e.
> Smalltalk), there are two possible ways to go: we share some
> kernel classes, we don't share
>
> 1) sharing model:
>
> We can give to the OS a complete environment with the classes. There is
> a stupid problem with subclasses (Object subclasses should only give you
> your  subclasses) and also what happens if you change the class format or
> method dictionary.  May be kind of VirtualClasses are a nice model for that
> kind of work. Or maybe it is another way to manage classes
>
> And off course in a shared model it should be possible to create a fully
> sandboxed environment.
>
> 2) we don't share:
>
> If we don't share each OS has its own full environment for me the problem
> is what happens if we want to communicate, that means that we share at least
> the symbol without that any try to send a message to another space will fail.
>
> 3) The best of both:  a way to do it is the share the kernel classes
> (Object, Behavior,
> Metaclass, ...) and make them in a read-only OS.
>
> In term of security sharing classes or not change nothing, we need a safe
> way to build classes because the virtual machine knows the format and
> needs a correct instanceSpec, method dictionary or correct compiled method.
>
> These points are just ideas, I like the idea of virtual classes, in
> fact with the OS
> environment we don't really need them. There will be a service which stores 
> some
> classes and when we build a new OS we will asks that service and it
> will copy the
> classes and link them with the kernel classes (which are R/O and should stay 
> R/O
> for most of the users)
>
> Sorry this is not clear, but these points are questions that I've in my mind,
> I am open to any critic and comments.
>
> For the sandbox mode we should be careful because this is not because we have 
> no
> access to external ref that the system is safe:
>
>  - create bad formatted cmpMethod, classes
>  - thisContext become: nil
>  - thisContext parentContext: thisContext
>  - finalization is dangerous too
>  - primitives should be restricted : ObjectMemory quit :D
>  - memory ressource
>
> On Thu, Oct 21, 2010 at 10:10 AM, Paolo Bonzini <address@hidden> wrote:
>> On 10/21/2010 12:09 AM, Paolo Bonzini wrote:
>>>
>>> However, maybe it's enough to have some _primitives_ redirected to the
>>> father ObjectSpace when the child ObjectSpace causes them.
>>
>> Thinking more about it, you can just replace the methods that call
>> primitives, so that they first consult the parent ObjectSpace.  You can then
>> use the existing trusted/untrusted mechanism to avoid _definition_ of new
>> primitives.
>>
>> Paolo
>>
>