[Help-smalltalk] Re: ObjectSpaces

[Gwenaël Casaccio]

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
>