Doug Way <dway at mailcan.com> wrote:
> Is there a situation where you'd have the global list of PI instances 
> in a more minimal image, but not have SqueakMap installed?  Could be, 
> but that might be uncommon.  I was thinking that the Minimal image 
> would still have the PI instances, which means PackageInfo would need 
> to be part of the Kernel, but I don't know if that's necessary.  As 
> long as it can add code to itself.  (That is when we take a serious 
> look at Spoon. :) )

It violates the privacy principle.  It is fine that SM must be loaded,
because it's part of the basic code-management infrastructure of Squeak.
 However, surely people should be able to make a package without posting
it immediately to SqueakMap.  In such a case, there is no SMPackage
entry, but you'd still like to have author, comment, and homepage url. 
I call this the privacy principle for real.  Personal images should not
need to make round trips to a global server in order to do basic
operations like creating a package.

Is it possible to whip up a SMPackage entry that is not attached to any
actual SqueakMap?  My impression has been that this doesn't make sense. 
If this one principle were to change--and a SqueakMap became simply a
list of packages that can be copied between multiple SqueakMap's
including a local per-image map--then I'd sing a different tune here.


Notice that the universes system *does* support packages which are not
associated with any particular server.  (And as a cost of this property,
a single universe cannot sensibly hold a catalog of *every* publically
shared package.)  The way this discussion is going, I believe Universes
can be modified to deal in whatever PackageInfo we end up with.  A
UPackage could then be a PackageInfo plus a UVersion.

The one thing that would need to be done, would be for PackageInfo to
have a list of dependencies.  A set of string names is fine.  Ideally,
it should also have "provides" and "conflicts", even though the current
algorithm in the univeres browser doesn't deal with these yet.


-Lex