Hi Lex!

I am going to try to answer each posting in this thread individually.

lex at cc.gatech.edu wrote:
> Hi Goran, I have loads of opinions on what I'd love you to donate your
> efforts  towards.  :)

I know. :) And I am listening.

> In short: I like SM a lot.  It is absolutely wonderful that I can tell
> people "Chuck is on SqueakMap".  It's even nice telling this to
> non-Squeakers.  But even though I like SM, there are some things
> missing, and I would argue to change over to something different if
> there were a system around that had those missing things.  I'd be
> delighted, though, if the "something different" were SqueakMap 3!
> 
> 
> Here are my thoughts on the directions you mention, plus a couple that,
> worryingly, you did not mention.  Let me say that in general, I am

I don't think you need to be worried - it was not an attempt to tell
all.

> coming from the perspective that a map on SqueakMap defines what Linux
> people call a "distribution".  In theory I may well have some wrong

I also have that perspective. I have recently moved over to Lunar Linux
on my desktop, which has a different system compared to Debian (it is a
Gentoo-ish distro) - better in some ways, less so in other.

> intuitions coming from that perspective, but so far that perspective
> seems to have been fruitful.  It seems like we are trying to do exactly
> the same thing here in Squeak as Linux people do with a
> distribution: there is a catalogue of packages that work together, and
> there are tools for users to browse the catalague, install stuff from
> it, and upgrade stuff that's in it.

Typically yes.
 
> Okay here goes.
> 
> 1.  While the word "file" is wrong, it is a defining characteristic of
> SqueakMap that it deals with serialized chunks of Squeaky goodness. 
> This is nothing to be embarassed about, and it would be wrong to even
> try to finesse this.  Our chunky goodness does not have to be stored
> on disks in files, but we still should have the encapsulated chunks.

Or to be even more precise - it deals with versioned (and thus frozen
snapshots) of stuff that can be installed into an image. It doesn't even
have to be "serialized" - as I think Craig would say that his modules
are not (when they are installed they are done so through a remote call
negotiation process).

But anyway - I agree in principal.

> 2. My number one desire, which is not on your list, is to stop talking
> about "the" map.  At the very least, there should be a map per version
> of Squeak, because in practice packages in Squeak 3.6 are not going to
> work in Squeak 3.0 unless you make at least a few changes.  Aside from
> that, as soon as you allow multiple maps to exist at all, you make it
> easy to think about clients pulling data from the union of multiple maps
> on multiple servers.  In short, it seems like a lot of the features you
> desire become simple if you allow multiple maps to exist per server, and
> for clients to pull packages from multiple servers and/or maps.

I know you have been talking about this before - and my answer is still
the same. :)
I don't see why all those "maps" can live in one map. As they do now.

And I am not sure I see which features that would be simpler with
separate maps.

Note for example that a map today - an instance of SMSqueakMap - holds
also all the accounts on the map with names, email adresses etc. And a
single account can surely own packages that work on both 3.2, 3.4, 3.5,
3.6 etc. It is in fact quite common. So I want to understand what it is
that isn't possible with a single map before I go in that direction.

Note though that I have a slightly different architecture in mind for
the future - a "tree" of servers where the clients are the leaves. But
that has nothing to do with the axis of Squeak versions ,but rather with
visibility of information (visible just for me, visible for my
development team, visible for my company, visible for all in the world
etc).

> 3. Number two is, as you suggest, to have dependencies between packages.
>  They do not need to be complex as we get going, but please do make them
> based on packages not particular versions.  At the distribution level,
> the dependencies should be like "Scamper needs URL", not "Scamper 1.5
> needs URL 1.3".  This is because, within a distribution, users almost
> always want to have the newest versions of the packages.

I will take that into consideration when I start working on that part. I
still think there should be a combination.

> 4. GUI tools instead of web browsing.  Yeah, that would be great.

Yep. :) That web UI has always been a temporary solution. That is why I
haven't spent one minute on "looks".

> 5. I don't understand the issues you mention with synchronization, but I
> see no need for SqueakMap to be messing with diff's.  If people want to
> diff between versions then let them use the code development tools like
> Monticello.

No, no - it wasn't diffs between packages. I was talking about how to
synchronize what happens when 204 maintainers start modifying their own
local maps instead of going through the single web master UI. *That* is
not a trivial thing.

> 6. Please maintain the property that I do not have to deal with UUID's. 
> We had this argument a long time ago and you said they would never ever
> show up to users, but I think you are starting to slip.  :)  You sent a
> post a few days ago saying that hand-written installer changesets should
> include UUID's in them....

Well, it is kinda funny. You don't want UUIDs, and Craig always tells me
that they are crucial.
IMHO I want them but I give you the choice if you want to use them or
not.

If I write a load script (and yes, that will eventually be phased out
when we get proper dependencies) I would want it to work regardless if
the package is renamed in the future. Thus *I* would use a UUID. But I
think almost all of those methods also have a name based variant.
 
> Just my thoughts, worth everything you paid for them!

I am collecting them. ;)

> Lex

regards, Göran