It is nice in principle, to reuse code whenever possible.  However, we
are talking about small amounts of code, that are going to be at the
center of our processes.  Surely we should do this right.  I think it is
a very bad idea, that everywhere we see name+author+comment, that we
think we have to use SqueakMap for it.  We have the option here of
adding a few variables to PackageInfo and continuing on our merry way. 
Let's please not stop here and argue that there's a theoretical better
way that we could instead use.

The problem is, what we need takes a large code delta from what a
SqueakMap package currently provides.  Extracting elements from
SqueakMap's is hard.  SMPackage has 17 instance variables, many of which
point back into internal data structures.  One of those variables is
called "map", which I assume is the map the card is in.  What do you do
with a package that is not in any map at all?  The SqueakMap model many
unique ID's, that will not be unique once multiple computers are making
up their own ID's, and there will have to be code written to deal with
the inevitable ID clashes.  (My vote, as an aside, is to dump the ID's. 
Use string names, and be very up front with the possibility that they
can clash.)

This isn't only my analysis, either.  Goran himself has said that this
kind of thing is hard!  It seems like the same kind of thing to move a
card from one map to another, as it is to combine two maps into a larger
map.  When I posted that this is my number 1 wish item for SqueakMap
last summer, Goran argued convincingly that it would require a large
code delta from the current SqueakMap.  (I still think this ability is
very important, which is why I did the Package Universes project.)


I would be (extremely!) happy to see SqueakMap redesigned so that
packages can be plucked from one map, copied to three images, and then
installed in a completely different map.  Based on this summer's
conversations, though, I don't expect this to happen.  And until it does
happen, SM doesn't actually give us what we need for in-image packages.

So, my proposal is:

	1. Move ahead with PackageInfo.

	2. Add some minor descriptive info to PackageInfo, like "description",
and maybe a url for more info.  It would be great for these to be there.
 The description should be a Text, ideally, just like class comments.

	3. Add some sort of variable, which optionally refers to a SqueakMap
package corresponding to that PackageInfo.  I defer to Goran for what
kind of info should go there, but the idea is, so long as the tools know
which PackageInfo goes with which SqueakMap package, the tools can do
all the same smart things they could do if PackageInfo were the *same*
as a SqueakMap package.


Everyone seems to agree with #1.  #2 is contentious, so consider this
email to be my 2 cents on the issue.  #3 is a possible compromise for
everyone who cares about #2.


-Lex