full isolation

[Mark Roos]

Your comments are similar to the issues that have led me to two use cases 
for "modules" in our
environment.  One of the cases, which I refer to as "Application", 
benefits from isolation from other
modules.   An application does not want to be affected by the loading, 
unloading or modification of
other modules.   It also has less need for the tight coupling provided by 
being in the same process
space.

The second use is for tightly coupled modules,  which I will refer to as 
libraries.  Libraries
are used by developers to create applications.  They benefit from the 
tight coupling, but suffer
some of the issues you mentioned like unexpected uverlaps,  modifications 
and load sequence dependent
behavior.  It would be nice to have a system which maintained the tight 
coupling while protecting
the programmer from the problems the tight coupling allows.

I would like to see an approach that supported both use cases.

mark








"Lex Spoon" <lex at cc.gatech.edu> 
03/02/05 04:50 PM

To
modules at discuss.squeakfoundation.org
cc

Subject
full isolation






There has been some murmering about full isolation, both pro and
against.  The idea is that modules will be totally insulated from each
other and thus unable to cause each other any harm.

It's a nice idea but terrible if you take it to the extreme.  Instead, a
module system should *allow* modules to hold stuff private without
interfering with other modules.  On the other hand, modules systems
should also provide convenient ways for modules to interact with each
other.  After all, the whole point of loading a module into your image
is to enhance what the image is already capable of.

Besides, full isolation is a royal pain if you really try it.  As a few
examples of what it would mean:

                 1. Every module must have its own thread.  Otherwise,

                 2. Modules must interact by passing messages or events, 
and not by
simple call and return.  Otherwise, when you call, the other module can
simply choose not to ever respond.

                 3. Classes need to be modified.  In particular, you can't 
let people
send #class to get a real class object, and then use #superclass and
#subclasses to browse around the class hierarchy.  You also probably
don't want modules calling #compiledMethodAt:put:.


I am not sure this extremity is a good idea for a module system even if
we had loads of time to implement it.  If you start with full isolation,
then it requires extra work to get modules talking to each other again -- 
and I am not sure that the benefits of isolation are always worth this
extra effort.

Regardless, it's not something that is achievable in 6 months, and also,
it's something that will break most existing Squeak code.

Thus, we all need to deeply accept that, when a module is loaded, it may
well cause some damage to the image it is loaded into.  Hopefully such
breakage is unusual, but it cannot be avoided entirely.

Instead, focus on trying to prevent common accidents, and to allow common
desired interactions.  Two modules accidentally defining a "Server" class 
is
a common kind of accident, as are two modules trying to add a ">>" method 
to
class Behavior.  What should happen, in such a situation?


-Lex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/modules/attachments/20050303/8c4011ac/attachment.htm