On Feb 13, 2005, at 11:16 AM, Lex Spoon wrote:

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

Basically, I agree.  The current proposal supports the privacy 
principle reasonably well IMO.

The current proposal being:  We have a list of PackageInfos (+comments) 
as the master list of in-image packages, which will be usable even if 
you don't have SM loaded.  You can create new PI packages with the 
standard browser in your image if you want, without SM knowing about 
it.  If you do have SM loaded, you also get the corresponding 
SMPackages (for known packages) with additional metadata, including 
URL, License, etc.  An SMPackage holds onto its PI package (if it's a 
PI-type package and not a changeset), and a PI package can look up its 
SMPackage if it exists.

(I'm not sure this jibes 100% with what Goran was envisioning, but I 
think it's pretty close.)

I disagree with you about the URL, I don't think it's really essential 
to have in the personal image PI package.  You can go to SqueakMap if 
you really need to find out more about the package out on the net.  But 
that's a relatively minor point.

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

A somewhat separate issue which I don't have a strong opinion on. :)  
But whether you have one global map, or multiple/local maps, a simple 
in-image package shouldn't *have* to know about any map as we agreed 
earlier.

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

Ouch, I'm not sure if we want to go there right now. ;)  Although a 
simple set of string name prerequisites would be kind of nice, if it 
was understood that PI will eventually be replaced with something else, 
including a more comprehensive dependency mechanism.  But these things 
have a way of sticking around forever once they're introduced. ;)

But yeah, just to simply know that the Morphic package requires 
Graphics as a prereq, and Graphics requires Kernel, etc, would be nice. 
  It would make unloading a little bit safer, e.g. if KomHttpServer 
requires the DynamicBindings package, then it could at least tell you 
that before you tried to unload DynamicBindings if you also had 
KomHttpServer loaded.

But we've been thinking we could wait until the Basic image is 
partitioned before adding a dependency scheme.  If you only have 10 or 
15 packages making up the Basic image, it's not *too* hard to keep 
track of the prerequisites by hand, for a little while at least.

- Doug