Hi Lex and all!

Trying to squeeze in an answer here...

lex at cc.gatech.edu wrote:
> 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.

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).

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

Sure. But all this is very doable. Adjustements to the UI, adding some
mechanisms like perhaps some permissions etc.

> 3. 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.

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

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

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".
 
> 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.

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

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".
 
> 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

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