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
|