Feedback

[Lex Spoon]

goran.krampe at bluefish.se wrote:
> Date: Mon, 7 Mar 2005 13:31:48 +0100
> From: goran.krampe at bluefish.se
> Subject: Re: Feedback
> To: packages at discuss.squeakfoundation.org
> mailing-list: contact packages-help at discuss.squeakfoundation.org; run by ezmlm
> 
> 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. :)


Yes, I was thinking that you probably have to have the servers  be
indepedent, at least in one direction.  You probably can't have the
local server being *required* to make round trips to the global server. 
Only probably, though.  I have not thought about it enough to close the
door on that design possibility entirely.  Mostly, it just seems right
that the local repository should be entirely under its own control, and
that we should be very careful about what requirements we place on it.


Being disconnected does change the design problems in one way: unique
identifiers can no longer be guaranteed.  One general strategy for
approaching this, is that if the local guy defines an identifier
identical to what the global server has, then the local guy is
*overriding* the global server -- just like with class inheritance.


Lex