Okay, here is a response to a few important issues in this thread.


1. Just to be clear, what I have called "multiple maps" is pretty much
equivalent to local servers plus the ability for a server to have
multiple parents.  I'll call it "multiple parents" from now on, if I am
talking about potential changes to SqueakMap.

2. SMCategories could be used to designate universes, but they are not
used that way right now.  It should be a big deal to put a package into
a universe, but putting a package into "3.6" is currently just a simple
click of the mouse in a web browser.  If we want to implement universes
with categories (not my prefered implementation), then we need to define
which category goes with which universe, and we need to modify the UI to
make it clear that teleporting a package from one universe into another
is a big deal that requires careful thought.  For some universes, it
should even require permission to add things in.



3. No one seems to get my distinction between a catalog of everything,
and a one-click no-hassle package installer, updater, and remover. 
SqueakMap, today, is a catalog of everything.  You can expect to go to
SqueakMap and find any package that exists.  However, you can't really
expect to click on an item in SqueakMap and have it install successfully
along with any dependencies it needs.  That's fine for a catalog of
everything.

In a one-click installer, though, you should not even *see* stuff that
cannot be installed.  You should not have to answer questions about
different versions of stuff, unless you have explicitly asked to get
into the nitty gritty.  Every package version you see in the tool,
should be consistent with whatever universe you are operating in.

All of these requirements seem to add up to a different system.  To
begin with, it seems both necessary and useful to admit that universes
exist and to have the tools talking about them.  One way to do that is
to associate different categories, maps, or catalogs with different
universes, so that you choose your universe by choosing which
categories/maps/catalogs to get packages from, but this kind of
association will not happen unless we plan for it.

Anyway, if you want SqueakMap to be a reliable auto-installer, then you
are pushing yourself to have to deal with the issues in this point at
some point.  On the other hand, if you are happy with it being a catalog
of everything -- a humongously valuable service -- then maybe a lot of
the issues in this post go away, because you can just tell people to use
some other tool if that's what they want.


4. As a general rule of thumb, it is nice if the system lets any
particular thing be decided in a decentralized way, even if we don't
expect to need it immediately.  No matter how benevolent a power is
controlling the central server, there are likely to be some cases that
someone legitimately wants different things locally.    Let's late bind
our policies.  :)  

That's the general decentralization mantra.  Let's consider one
particular case, to give you the idea: who decides what is allowed to go
into the map?  Several people have suggested that every package should
have an entry in the "main" SqueakMap server.  If you think about it,
though, there are actually plenty of packages that would make sense to
put into *a* SqueakMap, but not into *the* "main" SqueakMap server.  For
example:
	
	a. Home movies by one of my relatives.  The main SM will probably not
want to hold a terabyte of stuff that only a handful of people care
about.
	
	b. Stuff that is illegal to post on a server in some countries.  The
central server will probably want to shy away from such things, but
since such things include DVD-playing software, other people in the
world might reasonably want to do it.
	
	c. Stuff *offensive* to large portions of the regular Squeak community.
 I won't try to draw an exact line, but to get your imagination going,
SM should surely be child-friendly and religion-neutral.

	d. Stuff that is private to one organization, e.g. Disney's software
for a new ride at DisneyWorld.
	
It would be extremely nice if people in the above categories can use the
SqueakMap software without having to coordinate with any central Squeak
authority, much less having to register their packages on the "main" SM
server.  They don't want their stuff public, and for the most part
nobody else wants to see it, either.

This "what goes in?" question is just one example.  For just about any
property you can name for "the" SqueakMap, there is a legitimate reason
for some people to want to do something different locally.  We should
strive not to *force* these decisions to be made centrally whenever we
can avoid it.  We should strive not to hamper our future organizational
possibilities due to assumptions in the architecture.


5. Mixin repositories are very valuable, even though we don't need them
immediately.  Debian has hundreds of these, and it is only through the
mixins mechanism that Debian users can use Squeak itself through the
standard Debian tools.  In the above listing, everything in a-c is
likely to be prefered as a mixin; individual items matching those
categories can be independent from each other, and different people will
want different subsets of those servers to be visible in their universe.

Since mixins seem to be valuable, we should surely think carefully
before we make any architectural assumption that would make them
impossible.  Is the single-parent assumption such an assumption?  It
appears to be.


6. Goran asks about my solution for merging.  I look at class
SMSqueakMap and I see no problem with simply concatenating the variables
that come from the parents.  I really don't see what the big deal is,
because you would only try to merge SM's that are friendly with each
other and mostly consistent.  If the parent maps use different UUID's
for the same category, then it's two different categories.   If name
conflicts are bothersome, then rename one of them.  Etc.

At any rate, however hard it is to do a merge, it is only going to get
harder as the model gets more complicated.  If merging is valuable --
and it seems to be -- then the sooner it is addressed the less painful
it will be.

The prototype Universes package has merging in it, for any who want to
see its solution to merging.  Look at class UCompoundUniverse.

7. You say that the versioned configurations will automatically contain
unversioned dependency, but I don't see how that can be so.  Here is an
unversioned dependency:

	Scamper depends on URL
	
How can this be inferred from a big soup of packages like I have in my
present image?  It seems like the developer needs to give a hint at some
point.

Along these lines, can anyone give a *specific* response to the
A,B,C,Collections example, that uses versioned configurations?  Goran's
response either had the tool asking the user on the very first upgrade,
which does not seem the right behavior for a no-hassle one-click
installer, or it had some as-yet-undefined compatibility level.  How
does a compatibility level work, and is it really going to give
something more reliable than simply "grab the most recent version" ?


8. What "mess" in Debian is Goran talking about?  If SqueakMap worked as
well as Debian's apt I'd be ecstatic, so clearly I must be missing
something.  It is surreal to mention the mixing of testing and unstable
as a problem, because that is precisely what I am suggestiong that we
*not* do in the auto-install tool.  Testing and unstable are different
universes in Debian, and they should not be mixed.  In fact, the Debian
tools do *not* mix them unless you go hack the files manually or unless
you circumvent the main tools.  SqueakMap, on the other hand, has
everything mixed to begin with, which leads to people searching for ways
to separate the universes back out.



-Lex