**thanks**
I like this kind of discussions. (I hope to get someone working on  
solution 3 but money is scarce :)

Now about modules, I found several occasions (and this is also the  
idea behing open implementation of kiczales
before they went in aop) is that the boundary of modules are often at  
the wrong level of abstraction since
sometimes you want to be able to change deep implementation points.  
So in some cases (network for example)
people do not want to use library since they lose their ability to  
control low level.
Some people pointed to me ml functors with the experience that it was  
powerful but that often people were
using functors on functors on functors leading to system that noone  
can understand.

Stef

On 10 mars 07, at 22:16, Andreas Raab wrote:

> stephane ducasse wrote:
>> Did you encounter cases where you would have like to have  
>> different versions of the same component/modules running in the  
>> same image.
>
> Sure. Consider Croquet: It relies on replicated computation which  
> means that the replicated islands must have identical code based to  
> have the same behavior. But what happens when you link to a space  
> which uses a different (older or newer) version of a module that is  
> already loaded in the space you are in? As far I can see there are  
> only three options:]
>
> 1. Don't ever allow it. That's our current solution, i.e. all  
> spaces linked together must use the same code base. For the obvious  
> reasons this is neither particularly scalable nor desirable.
>
> 2. Force migration of "older" spaces. This may be an acceptable  
> solution if the number of spaces linked together is relatively  
> small. However it has the disadvantage that you create "waves" of  
> updates since participants are linked together in unforeseen ways  
> (compare this to a WWW where each web page can only be linked to  
> another webpage of the same version and where upgrading one would  
> implicitly require upgrade all the ones it links to - I think you  
> can see the basic problem with the approach).
>
> 3. Have these modules sit side-by-side. In reality, this is the  
> only scalable, secure and desirable solution.
>
> Cheers,
>   - Andreas
>
>