The future of SM...

goran.krampe at bluefish.se goran.krampe at bluefish.se
Sat Jul 24 15:55:27 UTC 2004


Hi all!

lex at cc.gatech.edu wrote:
> Guys, I never disagreed that it is possible to get along with a single
> map.  However, multiple maps seem to simplify some things and to enable
> some other things, all with no additional code beyond supporting
> multiple maps.

As Julian noted you disregard all the problems we will have to solve
with multiple maps.

> 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.
 	
> 	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. But - note - this is HARD to get
fully working properly and still make sure the model fits together
properly. For example - the category tree should be the same for all
servers etc.

In short:

1. The future SM will have a "single" map, but with multiple map servers
structured in a tree thus giving us local additions and scoped
visibility.
2. This is hard stuff to get working properly, unless we are going to
throw away stuff we have today.
3. This has nothing to do with Squeak version or any other partitioning
of the packages or their releases. It will ONLY affect visibility. 

> 	3. The ability to create nested universes and to have packages in inner
> universes automatically propagate to universes which contain them.

This is almost what I plan - but it sounds backwards. :) To be clear,
this is my plan with a few imaginary servers thrown in:

Master server - this is the current map1.squeakfoundation.org.
	Squeak client - these are the leafs of the tree.
				They can be direct under the master, like they are today.
	Impara server - let's say Impara sets up a server of their own.
		Michael's Squeak - Michael instead connects to the Impara server,
which knows it is
				a sub server of the master. 

Now, all the things in SM are sub instances of SMObject. The idea is
that an SMObject has a home map, it knows where in this tree it
"belongs" and it is visible to all servers below it. Thus, a package
that has the Master server as home map (like today) will be visible to
all Squeakers in the world. An SMPackage or even SMAccount (!) with home
map being Impara will only be visible below it - within Impara.

> 	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.
 
> 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. You are trying to make it sound as if having "multiple
maps" (whatever that really means, have you looked at what SMSqueakMap
contains? It contains SMCategories and SMAccounts - I would like to know
how those will be handled in "multiple maps".) is a nobrainer and
requires "no coding". This is just false.

Again, have you even looked at what SMSqueakMap contains today? Are you
aware of SMAccounts and SMCategory? Are you aware that SMPackage knows
its releases? And that the releases know which of the co-maintainers
published it? (=a reference from SMPackageRelease to an instance of
SMAccount) etc etc.

What I am saying is that the domain model is quite more complex than
just "a bunch of package descriptions" and thus you CAN'T easily just
split it up on a bunch of servers.
 
> 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.

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

> They should be able to do this even if they
> aren't following the main development version, and they should be able
> to integrate their own packages into the system without needing
> cooperation from a central authority.  If SqueakMap is not intended for
> these purposes, then we should put together something else.

I am not sure what you mean with "not following the main development
version".
The part with integrating their own packages though is definitely
planned in SM - I explained it above. The reason for not moving in this
direction until now is simply because it will be quite complex to get it
all working smoothly. It was simply much easier to have a SINGLE master
model on a server, especially when it has been evolving over time as it
has.

SqueakMap IS intended for 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?

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

> this is typical, then the configurations will always be ignored by the
> user, which makes them pointless.  If we want a dependency system that
> the user will practically never want to override--and I think we can get
> there--then it seems that we should not put fixed version numbers in the
> dependencies.

Lex, I can only say this:

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. Given this approach two things are apparent:
	- Recording the exact information available. There is simply no POINT
in throwing away info.
	- It must be very easy to both:
		- Record a working config
		- Deviate from the information so far collected.

I have tried to explain these ideas many times. I think it will work. It
does NOT force the user in any way - in fact, it will be MUCH more
friendly than say Debian, because the engine will be able to give advice
based on the release compatibility levels. And thus people will not be
afraid to try to use newer releases and they will thus discover and
record if it works or not.

Now, enough typing. It doesn't feel productive. I get the feeling you
are not listening to what I have to say and you are not even
contemplating that it can be solved in a better and friendlier way than
in Debian. Debian is nice, but it ain't perfect.

As I have said before - we use Debian on all our servers and it was the
main inspiration for SqueakMap. But it is not the perfect solution -
especially not for Squeak which is different in many ways.

> Overall, I have followed communites where the packaging system causes
> its users headaches (RedHat, Windows DLL's), and I have seen one
> community where the packaging system Just Works (Debian).  I have
> thought about this issue a good bit, and I am simply pointing out some
> conclusions that I expect will make our system work better.  Squeak is a

Yes, you are pointing things out - but it doesn't seem that you have
looked at how SqueakMap works.

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

> -Lex

regards, Göran



More information about the Squeak-dev mailing list