Hi Goran, I have loads of opinions on what I'd love you to donate your
efforts  towards.  :)

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
coming from the perspective that a map on SqueakMap defines what Linux
people call a "distribution".  In theory I may well have some wrong
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.

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.

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.

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.

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

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.

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


Just my thoughts, worth everything you paid for them!

Lex