Hi people!

Doug Way <dway at mailcan.com> wrote:
> 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

I have never argued they couldn't make a package without posting it on
SM.
Of course they should be able to. IMHO PI is orthogonal to SMPackage and
that is exactly how I want it too.

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

I am just slightly curious about the need for author and homepage url if
the package isn't meant for anyone else than you privately. And of
course, SM isn't perfect - as you have written quite a few times it
isn't distributed yet with ability to have "private" SM packages, but it
is still on the agenda.

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

It sounds perfectly like I envision it. You know guys, I just want us to
not reinvent stuff - I hope you Lex can understand that point of view.
And the shortcomings of SM - sure, there are a lot and I want to adress
them all. And btw, as always I am inviting people to help me and as
always noone comes forward. :)
 
> 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.

Agree.

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

Agree.

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

Well, obviously I need to get my dependency stuff finally out the door.
:)

> 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

Btw, the whole discussion about PI subclass or not - at this point I
don't have a good opinion.
There are arguments both ways it seems.

regards, Göran