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:
- 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.
- 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.
- 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?
- 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