Hey Goran, I truly have been reading what you and others post.  For
example, I showed that Julian's "problems" are actually easier to solve
with multiple maps, and no one responded.  Also, I truly am familiar
with the details of SqueakMap that you are describing, though I have not
delved into the details of its implementation.  Please do take what I
say seriously; I am not just covering my ears and harping my favorite
tune.

There are two main desiderata I mentioned that you say you are not
planning to implement: simple unversioned dependencies, and allowing
clients to pull from multiple maps.

On dependencies, I would love if you were to actually step through
either the example I posted or one of your own. Any example will do so
long as it is not in lockstep and so long as you do not require
interaction with the user to make the decisions.  What do you envision
the package loader will do at each step?

	http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-July/080076
.html


In the multiple maps question, I can boil the issues down to two
scenarios.

Scenario 1: Someone wants to provide a mixin server that can be used to
provide packages to multiple package universes.  How do you support
this, while allowing end users to use several different mixin servers in
the same image?

Scenario 2: Your local organization makes its own SqueakMap server, with
potentially its own user accounts, packages, and policies about package
updates.  The local server wants to be an extension of Squeak 3.7final. 
Can the organization do this without *any* interaction with a central
Squeak authority?

Both 1 and 2 are trivial if the client pulls from a list of maps instead
of just one map.

Scenario 2b: What if HP and Compaq each have a local SqueakMap server,
and then HP acquires Compaq and they want to merge the server contents
together?  There is some inevitable pain from this, but how can we
minimize it?  Multiple maps help on 2b, though there are more issues to
consider as well.



These said, here are some individual comments:

> > With multiple maps, you immediately gain the following
> > abilities:
> > 
> > 	1. Keeping track of which package releases are in which Squeak
> > versions, with a UI that requires no extra activities by the users.
> 
> I can't understand what you mean. With multiple maps you will have to
> choose the "3.6" map in order to see the "3.6" packages, right? And with
> multiple maps I will need to select which maps to register a release in,
> depending on which Squeak versions it works in, right? Again, no
> difference compared to what we have now.

You have the general idea, though are missing one important difference. 
With multiple maps, each image can *implicitly* specify a universe it is
operating in via the list of maps it is pulling from.  Then all the
tools need no further interaction with the user.  Both when downloading
packages and when uploading packages and when uploading thumbs-up
notifications, the tools will Just Know what to do.

Anyway, even if you disagree that the multiple maps approach is a better
result, the really big point is that multiple maps gives it to you with
no further code.


> > 	2. The ability for users to set up their own package universes without
> > needing to coordinate withany central authority.
> 
> This is planned. The idea is to have a tree of map servers in which you
> add local additional information, thus you can have local packages only
> visible to you, or your company etc.
>
> But this has NOTHING to do with which Squeak version things are meant
> for. It is purely a visibility thing - and the servers are still clearly
> connected with each other in a tree. 

I don't understand your "nothing" comment, because visibility and
versions-meant-for (I'd prefer universes-meant-for) are the same thing. 
But I'll procede on the parts I understand.

Trees of servers are very close to what I am talking about,  but they do
not give you the full functionality that multiple maps do.  In
particular, they do not support "mixin" servers such as the ones in
Debian for DVD software and updated Java plugins, etc.  There are
hundreds of these mixins nowadays, so it is a valuable feature to
support.  To support mixin servers, though, you must allow the nodes of
the trees to have multiple parent nodes.  And once you do that, you are
doing exactly what I suggest, only at the server level instead of in the
clients.


> 2. This is hard stuff to get working properly, unless we are going to
> throw away stuff we have today.

I agree that difficulty of implementation is a important.  However, it
needs to be compared with the difficulty of implementing alternatives. 
Also, isn't it bothersome if a union operation is difficult to
implement?


> > 	4. The ability for a package to be maintained by different people in
> > different package universes, e.g. if I only support Chuck in 3.7, Joe
> > can volunteer to support it in 3.0.
> 
> This already works today with co-maintainers.

It mostly works, though it currently requires central coordination. 
What if it's Jose wanting to support the Spanish version of Chuck?  Jose
should not need permission from me, and he should be allowed to call the
package "Chuck" on the Spanish SqueakMap.  More on this below.



> > I find this list striking, when one considers that all of these features
> > happen automatically and with no coding at all.
> 
> That is not true.

I meant, no coding beyond the coding necessary to get multiple maps.  Do
you disagree that multiple maps would give you the things I describe,
with no further coding?





> > Now, perhaps I am misunderstanding the purpose of SqueakMap.   If
> > SqueakMap wants to be a catalog of everything, then I have misunderstood
> > and that is fine.   In that case, however, I do suggest that we start
> 
> Have you read the article I recently posted on SqP? It explains quite a
> bit about what I want SM to be. And yes, it was just recently posted so
> you may have not seen it yet.

No, I haven't.  Thanks for the pointer; I look forward to reading it.



> > work on a new tool which is a "package universe browser".  Users should
> > have some tool that lets them select packages from a menu, install them,
> > and have it just work.
> 
> Hmmm, and what is the package loader you think?

It could be either one.  Do you see what I mean between the difference
of a "catalogue of everything" versus the toolset that would support
package universes?  SqueakMap clearly started life as the former, and it
sounds like it is now trying to be both the former and the latter.  It
may simplify things to divide SqueakMap into two parts, one for each of
these purposes.



> > Regarding versioned dependencies, Julian, Goran did indeed call the
> > configurations "dependencies".  And please consider that in the A,B,C
> 
> I don't know when I did - it sounds "wrong" but I may have slipped my
> tongue sometime. Can you point me to it?

I am glad that you are not calling these dependencies any longer. 
However, when I made my post earlier, you did halfway object to my
request to have unversioned dependencies:

	http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-July/080026
.html

Also, here is a direct quote from a while back where you call it a
"dependency conflict" that the configurations have not been solved
happily:

"Hey, Mungo 1.3 has a dependency conflict with Pingu 1.2. They both rely
on Zingo but Pingu has only been verified to work with Zingo 2.0.
According to the compatibility level of Zingo 2.0 it is categorized as
*compatible* (=level 4, changes have been made but the maintainer says
he hasn't changed the API so it should work), would you like to use that
instead?"


If they aren't dependencies then why do they give a "dependency
conflict"?



> The configuration model I have in mind is more about having users and
> maintainers "recording" working configurations so that other people,
> using an engine, can install packages and needed dependencies in an as
> easy way as possible. 

Here you are calling them dependencies again....



> 	- It must be very easy to both:
> 		- Record a working config
>
> 		- Deviate from the information so far collected.
		
		
Sure.  Please remove the "must", however.  And by the way, it is
interesting that you consider the second so important, when Debian is
doing quite well without it.


> > example there was *never* a time that I could upgrade *any* package.  If
> 
> This sounds very wrong. Julian responded on this topic and it is
> probably purely useless for me to reiterate what he wrote.

What would be useful would be for someone to make a concrete proposol of
what should happen in examples like the one I described.  No one has
done that.  They simply say the configurations should be ignored. 
Doesn't it beat the purpose, though, if all this great information is
simply ignored by the tools?



> I have tried to explain these ideas many times. I think it will work.

And I hope you succeed.  This is a wonderful rallying center of our
community.



> Debian is nice, but it ain't perfect.

It is also proven to work, as I'm sure you agree.


> > decentralized playground, though, and everyone is free to play in it
> > however they like.
> 
> Of course. But SM is such a central piece to the community, that I want
> as many as possible to like the way I am pushing it. I can't of course
> convince everyone - but just so you know - this is the main reason I am
> discussing this so much on this list.


One last thing.  After reading this post and skimming your Squeak People
article, I see that you are trying to centralize various aspects of
SqueakMap.  This seems like a good idea, but let us please be wary of
building centralist policies into the architecture itself.  Squeak is a
loose community to begin with, and it seems overly ambitious to try and
force people to organize more rigourously when they haven't decided to
already.


Let me give some specific examples.  Here are some things that should be
doable at a local level, without involvement from any central authority:

	1. The creation of new universes that draw packages from an existing
one.  The local guys should not have to coordinate with the server you
are drawing from.
	
	2. The creation and maintenance of user accounts.  Individual
organizations should be able to have their own accounts without
publishing them publically.
	
	3. The designation of who has permission to post package versions to
each server.  Particular package universes should have their own rules
about this, that even the original owner of a package cannot necessarily
override.  (Even though in the main Squeak repository, we want to give
more deference to the designated package owner.)

You may not be surprised at this point, but multiple maps gives you
these decentralized policies automatically, and also, Debian manages its
policies in a way that gives the above properties.  While these
properties are not strictly necessary, they are both desirable and
attainable.


-lex