Hi Lex and all!
Trying to squeeze in an answer here...
lex@cc.gatech.edu wrote:
Okay, here is a response to a few important issues in this thread.
- 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.
Yes, I am still "reflecting" on the various use cases and effects. :) We will see. It is currently on the "back burner" though, I want to incorporate a solution for dependencies first (including making it possible for Stephan to experiment with his model).
- 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.
Sure. But all this is very doable. Adjustements to the UI, adding some mechanisms like perhaps some permissions etc.
- No one seems to get my distinction between a catalog of everything,
and a one-click no-hassle package installer, updater, and remover.
Well, I think see the distinction.
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.
Of course not - because it doesn't *have* dependencies yet. Pretty obvious to me.
That's fine for a catalog of everything.
In a one-click installer, though, you should not even *see* stuff that cannot be installed.
This is just filtering, trivial IMHO.
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.
Fine, again filtering and preferences.
All of these requirements seem to add up to a different system. To
I don't agree. :) I just see it as new use cases and requirements that we need to implement.
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.
My biggest problem with "multiple maps" (in a loose meaning) is that we very likely will loose the very important aspect of today - there is ONE place to go to. I don't want to chase around looking for "maps" etc. Why should I need to?
I want to solve the use cases and STILL maintain our very nice complete singular place that we can go to.
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.
I am. All the time. Why do you think I am working on dependencies?!
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.
I want to solve as many use cases as possible. I have always wanted to do that.
- 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.
You know - I have always planned for this! That is the whole point with many of the use cases for the new architecture which I was planning as a tree of servers - and now am undecided on.
You make it sound like I am opposed to this - and I am NOT. Really.
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.
- 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.
Well, I am rethinking the model after discussions with Julian. I still don't want to end up in a world where people have to hunt around for "maps".
- 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.
Well, you are ignoring several cross links in the model, but whatever I don't bother discussing that anymore...
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.
Well, I have chosen to get the model a bit more evolved first - dependencies. Then I will go for the new arch.
The prototype Universes package has merging in it, for any who want to see its solution to merging. Look at class UCompoundUniverse.
- 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.
Don't understand. But whatever. If Scamper-r1 depends on URL-r3 then I see the dependency, don't I?
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" ?
What?! I gave you a *specific* response exactly along my model. And the questions can easily be changed to auto actions based on preferences. The compatibility level IS ALREADY ON SM. Just create a new release and you will see. And I have explained TONS of times what it is.
Sigh. I gave my "specific response".
- 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
Well, you can't compare the two when SM HAS NO DEPENDENCIES YET.
as a problem, because that is precisely what I am suggestiong that we *not* do in the auto-install tool.
And *I* am suggesting that it will not be problematic to do it in MY model.
Testing and unstable are different universes in Debian, and they should not be mixed. In fact, the Debian
What do you mean should not be mixed? I think that is up to the user.
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
That is wrong AFAIK. I used Galeon from unstable when running testing. Don't recall all the details on pinning etc, but mixing sure is doable.
everything mixed to begin with, which leads to people searching for ways to separate the universes back out.
-Lex
regards, Göran