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 <bonz...@gnu.org> 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 > _______________________________________________ help-smalltalk mailing list help-smalltalk@gnu.org http://lists.gnu.org/mailman/listinfo/help-smalltalk
