Partitioning the image (was Re: Shrinking sucks!)

Lex Spoon lex at cc.gatech.edu
Fri Feb 11 15:26:40 UTC 2005


goran.krampe at bluefish.se wrote:
> 
> Package comment - fine. I agree.
> Reimplementing the whole meta model around packages that SM provides?
> 
> No, I don't agree.

Can you elaborate?

Please consider a few scenarios.

First, suppose I create a package in my image, but do
not register that package on SqueakMap.  Surely this
should be allowed?  I don't have to publish *all* of my half-baked
experiments, do I?  In that case, how does my image record the existence
of that package?

A second scenario to consider is: I create a package locally, and
someone else creates a same-named package on the public SqueakMap.  I
then run "update" on my local SqueakMap.  What happens?

Third, what if I want to download a package from SqueakMap, and then
change it in my local image?  What are my options?  I (rightly) cannot
change other people's packages on the public SqueakMap, but can't I do
it locally if I desire?  It's my image, after all!

I can summarize all three scenarios with a property I think we should
aim for: individuals and individual projects can still hack their
private images arbitrarily without needing to share with the general
public.  Ideally, projects can share with their own members without
sharing with the general public.  This could be called the "privacy"
property.

Without the privacy property, people can still keep things private, but
to do so they have to completely abandon the public infrastructure.  As
much as possible, I want to aim for a Squeak community where all the
different projects can share the *portions* of the projects that overlap
and make sense to share.  I don't want to end up like the Scheme
community if possible.

Maybe this relates to the "world view" argument that came up in an
earlier trhead.  I adamantly believe that people should not have to
share with the public every time they press alt-s.  But of course, if
you disagree, and think everyone's image should be visible to the
public, then you will reach different conclusions about how to handle
the packaging infrastructure.


Anyway, if you are suggestiong "just use SqueakMap", I disagree that it
solves what we want.  Images need their own model of what packages are
present, etc., and this will be slightly different from what is
registered on SqueakMap.  (And, as I've argued in the past, that in turn
is different from participation in individual package universes.)  

Keep in mind that package models do not need to be complicated.  The
entire initial universes system, including packages, versions, the
server, the browser, and the editor, took 2 days to implement. 
PackageInfo, for all its importance and impact, is a measly 206 lines of
code.  We should not be terrified of burning the "disk pack" in this
case.  It's more like burning 5 sheets of paper.

All this said, of course we want everything to interact nicely with
SqueakMap.  It would be very good, for example, if packages in a local
image can be optionally connected to packages.  This might be called the
"interop" property: all of our development infrastructure, including
squeakmap, universes, monticello, squeaksource, and ideally the bug
tracker, should interoperate nicely.


-Lex



More information about the Squeak-dev mailing list