The future of SM...

Richard Staehli rastaehli at mac.com
Fri Jul 16 00:24:50 UTC 2004


On Thursday, goran.krampe at bluefish.se wrote:

> Anyway, this leads me to the following questions that I need answers 
> to:
>
> - Does the community want me to continue my work on SM? If the answer 
> is
> no, I will drop it immediately, I don't have time to waste on a dead
> project.

Please continue.  I'll would even pay for the benefit I've received 
from your work.

>
> - If the answer is yes, I will equate that to mean that you want SM to
> evolve into the future and not just be replaced with something else. 
> For
> my future plans, see below.

I expect something else, whether it evolves from SM or not.  I would 
prefer that it be an evolution, but there are many ways to move 
forward.  I'm working on a component architecture research project that 
could influence how we move Squeak beyond the monolithic image.  There 
is a big overlap of concerns between my work and SM, but I do not view 
it as competition.  I just stub out the parts that are already 
addressed by SM or other technology.  My prototype work 
(http://www.simula.no:8888/QuA) is still (sigh) not ready to 
demonstrate, but when it is, I will want to integrate it with SM and 
will welcome collaboration.  Of course, we have been engaged for two 
years in trying to collaborate with the middleware community and to 
publish our initial results.

A few bullet points regarding how I hope SM (or other Squeak module 
architecture) will evolve:
- persistent object names based on logical repositories not tied to an 
internet name
- peer-to-peer protocol for creating and maintaining global persistent 
object (including code) repository
- code references component types, allowing substitution of 
implementation (classes)

I'd also like security mechanisms assure that code from a trusted 
repository is unaltered.

> - If the answer is yes, is it fair of me to ask people to collaborate
> with me on how SM works and how it should evolve instead of people
> building replacements? If I together with other interested parties 
> can't
> evolve SM into the future - then I will be glad to step down and let
> someone else do it. But I would like the chance from the community to
> evolve SM in the direction it wants to go and I would happily be
> convinced about new ways of doing things in SM, like for example the
> problem of meta catalog distribution/synchronization, see below.

No, you can't expect people not to think/work/play with replacements, 
but I expect most will be happy to share their ideas with you if not 
collaborate on SM.

I'm just very busy with my work (and soon my vacation) but will 
continue to look for ways I can help with SM.

Richard Staehli




More information about the Squeak-dev mailing list