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 <[email protected]> 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 <[email protected]> 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 [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
