Hi all!

(back from China and will have limited time the next weeks)

Stephan Rudlof <sr at evolgo.de> wrote:
> Hello Craig,
> 
> I think, after your proposal you have *one* *logical* map, *physically*
> distributed over multiple submaps connected via some network, building a
> graph of nodes being all at one level (no hierarchy).

Yes, this is my perception too. The discussion is going around in
"circles" here.

I said "let us stick to ONE logical map, although with an architecture
of *connected* multiple servers offering public/private additions etc".

Lex says "let's have multiple *disconnected* servers with MULTIPLE maps
that the clients can merge together like they please". My response is
that such a model is bad because suddenly we have lost the ability to
enumerate the full information space because just like in Debian there
is no "map of the repositories". And I have also expressed multiple
other worries about the complexity of it all, yadda yadda.

Then Craig says "but we can connect all those servers in a network" -
aha! But that is what *I* have been saying all along! :) Although I am
trying to make it vastly simpler with a tree instead of a graph.
 
> This sounds more complicated as using a hierarchical graph like
> - one logical map at one server, as current;
> - one logical map distributed over a tree structure of servers (with
> childs all sharing the same parent content), as planned;
> - one logical map distributed over a tree structure of servers (like the
> former), with *mirrors* for some important nodes (e.g. the top node) for
> improving robustness, as making sense IMO.
> 
> In such a hierarchy it is always clear, where to look for *all* the
> public packages (and their dependencies), seen from the local node;
> namely at the immediate parent (or its mirror).

Exactly.

> Multiple parents with *different* content (in opposite to mere mirrors)
> seems to be more difficult to realize to me than the former variants,
> and the complexity of your proposal comes thereafter.
> 
> The advantage - to be fair - of such a highly decentralized solution
> would be, that it could be very robust against technical or social
> failures in large parts (the internet is an example).
>
> The disadvantage would be, that installing some dependency mechanisms
> appears very difficult to me in such a scenario, too. For dependencies
> there has to be some place (the resolver), where all needed ones are
> available at a whole! And not all of them are to be coupled to a certain
> package: e.g. conflicts of some configurations may be detected later and
> be stored aside the packages. In addition it probably makes sense to
> have some control about who is allowed to change the dependencies, which
> also seems to be more difficult to reach in a fully decentralized model
> than in a hierarchical one.

Again, exactly.

Now... I am dead tired of arguing all this. :) I need to code and make
things happen.

I am aware of a number of "use cases" that Lex wants to enable and that
are harder in my model. I intend to really try to enable those - the
most important one being IMHO to be able to have non-public SMObjects on
non-public servers and perhaps even be able to somehow combine multiple
such non-public servers.

But I still don't buy the "universe" idea. There are various reasons for
this. One major reason is that I don't think we - the community - have
the energy nor the actual need to maintain multiple universes that Lex
is describing.

The lack of energy is pretty obvious - we even have a hard time
maintaining the Full assembly. :)

And what about the needs? We have been comparing with Linux distros a
lot but I don't think the comparison should be taken too far. Because I
think that we are making a mistake if we think that Squeak has the
*same* issues.

For example - most of us I think use Squeak to build applications. We
don't use Squeak as an OS. We frequently construct images targeted at
certain tasks. I have myself multiple images for different purposes -
and often I run 4-5 of them concurrently. One for developing SM. Another
for using BFAV. One "throw away" for playing with packages from SM. Yet
another for developing a web app, and so on. Each image I taylor for the
task. I install a selected few pieces, a few tools I like, a few
"libraries" etc trying to keep each image pretty clean.

Now - does this sound like how I use Linux? Nope. Sure, I build targeted
servers with Debian too - but that is not what I do "daily". :)

My view is that we are *primarily* a community of package *developers*.
We write code and then we publish that code in releases. We have a
pretty good idea about the dependencies of the code we have written and
we can take the time needed to describe it - if there is a mechanism for
doing that.

We are in general not a community of people that like maintaining
distros - again, just look at how few of us that actually do the work
for maintaining Full etc.

My conclusion from this is that we should strive to describe our
packages and their releases as good as possible (including dependencies
etc) *individually* and then let the user "pick and choose" among them
in a semi-automated controlled manner based on those descriptions.

Or putting it another way - it seems to me our tools and our model
should be focused on helping the user to compose an image from packages
instead of fooling ourselves to believe that we will have the energy or
interest to compose "distros" for others to use.

Well, I may be right or wrong. :)

regards, Göran