Hi Richard!

Richard Staehli <rastaehli at mac.com> wrote:
> 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.

Hehe, really? :)

> > - 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.

As soon as you want to talk - I am here. :) The two first points you
raise I will probably not pursue early - the first one I am not exactly
sure what it means, but I assume it has to do with moving away from URLs
and having a global shared object space instead somehow. The second has
to do with the same thing, although p2p generally is complicated and
beside the buzzword value, I would like to know the benefits compared to
say a more structured tree of servers.

The idea of substitutable components has to do with Namespaces (I would
say) etc and is slightly outside SM, but would of course also affect how
SM deals with the possibilities opened.

Security is certainly lacking today, both authentication and well,
md5sums or similar. Adding md5 would be trivial though, perhaps I should
do that now.

> > - 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 agree - and that one came out a bit wrong perhaps. I was thinking
"aloud". I can't expect that.

On the other hand this is a community and as I was saying on IRC
yesterday (when I apologized to Craig about this posting btw) SM is a
bit different than other projects.

First of all a large part of the value of SM comes from its singularity.
A global catalog for the community is much more interesting if there is
only ONE. Perl has CPAN. Debian has it's apt-get. It is crucial that
there is ONE agreed mechanism - having competing such catalogs is IMHO a
bad thing.

Secondly SM is worth zip to me personally if it wasn't used as the
catalog of the Squeak community. In other words - SM is purely a project
for the community - I nor anyone else have any interest in it if it
wasn't used as it is meant to be used. All that code would simply be
wasted.

Now - almost all other projects that we work on has an area of
application. Someone uses them for something, at the very least the
developer himself. Ned uses Connectors. Chris uses Magma. Avi uses
Seaside, etc etc. But I can't "use" SM on my own. VMMaker is slightly
similar to SM - it is one of those projects that is so much better if
there is only ONE, but it isn't useless if there was a competing
solution that some preferred. But the SM codebase would be totally
useless.

This last point is important for you guys to understand why I am so
emotionally involved in this and why I react like I do. In short - this
is a community dammit :), and please, please, please talk to me about
working *with me* on SM before you go about building a replacement. That
is *ALL* I ask. I don't expect you to not build replacements, but I *do*
expect you to talk to me first.

And if you after that still think there is no way to pursue your ideas
by collaborating with me on SM - then fine. I will not stand in the way.

> 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

I look forward to any help offered. :)

regards, Göran