Getting Ready

[Mark Roos]

Dan, I had no reason to limit the conversation to you,  just an email 
error.

In way of explanation on my question I have a product  which is a single 
image consisting of 50 or
so applications.  Each application is built from 'modules' which are 
groups of behavior managed by an individual.  Updates
are performed by 'patches'  which are autoloaded at image startup and are 
created by whoever discovers the problem.

Some requirements were for distributed autonomous development. kibitzing 
of others code and a desire by our users to never
have a bad experience due to upgrades.

While this was a good approach when we were developing code now that we 
are in an incremental enhancement mode we are finding that
keeping the applications running while updating the modules is becoming a 
pain. 

After looking at our options I am pursuing the concept that each 
application is its own image, modules namespace and patches thus moving 
away
from the single image approach.  Of course to make this work I need to 
keep the nice parts of a common image such as object
communications between applications and sharing of the cpu.

With this in mind I have some interest in your idea to have multiple 
projects ( similar to our applications ) in a single image.  This
appears to have some of the characteristics that I am looking for but it 
seems like the separate image approach offers a cleaner
separation.

Do you have any thoughts on the relative merits of the separate projects 
in a single image vs the independent project per image approach?


mark





Dan Ingalls <Dan at SqueakLand.org> 
03/01/2005 12:46 PM

To
Mark Roos <mroos at roos.com>
cc

Subject
Re: Getting Ready






Dan stated.
Now imagine that the VM can have multiple method caches, one per, um, per 
process?  per module?  Think about it.  And when you have figured it out, 
note that this system could run simultaneous multiple projects with 
conflicting changes to root classes with no performance degradation.

How do you envision this being different, or better, than several 
independent Squeak processes with some form of tight message based 
communications  and a good scheduler?

Hi Mark -

I'm not sure what you're proposing as the thing to compare against.

In Squeak there is no current way to have conflicting changes to root 
classes.  Can you spell out a bit more what you mean by the above 
one-liner?

p.s. I am liking a lot the idea of using the cache to handle overrides

Me, too.  We've already got most of the mechanism, and putting a level of 
indirection on it offers a lot of leverage.

        - Dan

By the way, it's fine with me if you'd like to include the list on this. 
It's also fine to keep it offline.  Just wanted you to know.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/modules/attachments/20050301/3a481b8a/attachment.htm