Feedback

[goran.krampe at bluefish.se]

Hiya!

Avi Bryant <avi.bryant at gmail.com> wrote:
> On Mon, 7 Mar 2005 08:58:56 +0100, goran.krampe at bluefish.se
> <goran.krampe at bluefish.se> wrote:
> > Evidently it is dangerous not being online for a weekend.
> 
> Ah, I wondered why squeak-dev was so quiet... ;)

:)

> > 1. If I read you right Avi, you suggest us sticking with PI as it stands
> > today.
> 
> For now, yes.

Good, because I agree. :)
 
> > Also, Ned has recently posted a
> > "power pack" for PI including some split-changesets-based-on-PIs that I
> > and he wrote independently.
> 
> http://map1.squeakfoundation.org/sm/package/fd191d06-6efe-4fde-ab0e-f1225059e8f0
> Yes, that will be very useful for the partitioning work I'm sure.

Ah, right - he put it on SM, perfect.

> > 2. Your initial post didn't clearly express the idea that we can indeed
> > "stake out" the image without having to actually "break out" parts of
> > it. I think that piece of the puzzle is important.
> 
> Agreed.  I would put it this way: in most cases, it is more important
> to be able to save and update parts of the image as packages, than it
> is to be able to unload and load those same parts.

Exactly, and it is even good if we can just stake out parts and still
maintain them using the update stream. Sure, if we stake them out (PI)
then of course we have the ability to do both, depending on how we wish
to do it. Anyway, my main point is that we shouldn't let the fact that a
part is tightly intertwined stop us from staking out the image. Sure,
some of the boundaries will be a bit loose - but we will still be able
to map each method to a Steward. :)
 
> > 1. Lex mentions a few needs currently not being addressed by SM. One is
> > the ability to have "private" repos - or in other words to decentralize
> > SM into multiple connected servers in some way.
> 
> A small clarification, here: what I believe Lex and I were talking
> about was not "multiple connected servers", but multiple independent
> servers.  The client should be able to integrate the information from
> these various servers, but I don't believe that we need or want the
> servers themselves to be aware of each other.

Sure, but the problems are mostly the same - how to manage a complex
object model in a distributed manner. :)

> > 4. Universes. I intend to look into Lex's code again more carefully and
> > try to figure out how to either:
> >         a) Make it work "with" SM. But this is only interesting if Lex or
> > someone else wants to continue maintaining Universes and nor merging it
> > with SM.
> >         b) Merge the concepts and mechanisms with SM so that the sum is greater
> > than the parts.
> 
> Yes.  One thing that I'm hoping will come out of this list is a better
> understanding of how to have one solution which has the advantages of
> both.

I am intent on making sure SM evolves in the best plausible way.

> Avi

regards, Göran