[Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff)

[goran.krampe at bluefish.se]

Daniel Vainsencher <danielv at netvision.net.il> wrote:
> goran.krampe at bluefish.se wrote:
> > And SMPackage again - is a "public" package used by others.
> > 
> > So my conclusion is that both concepts are valid and disjoint but we
> > should try to NOT introduce any *more* of these "kinda-module-thingies"
> > into the Squeak world. :-)
> 
> On the contrary - it isn't that we have too many "kinda module
> thingies", it is that we (ab)use the word "module" to describe an

I don't think we have too many either. I just meant that we only need
ONE per construct - as you describe below. So in short we are in
agreement - I just slipped with the words.

> imaginary construct that's supposed to solve too many different
> problems. Here's one way to cut it -
> * Unit of code reuse (which brings with it issues of  understanding
> changemanagement)

Yes, and here we have typical source management stuff like PackageInfo.

> * Unit of program deployment (including issues of mixing different
> versions of modules)

Right, that is where SMPackage fits.

> * As used by some people, may also include Namespaces, distributed
> transactions, partitioning of non-code objects...

ImageSegments, Magma etc I guess.

> To the extent that we're clear about which design is meant to solve what
> problems, constructing the overall solution from a few more pieces won't
> hurt too much, and will give us flexibility (DVS today, Monticello
> tommorrow).

I agree fully. I was just trying to note that the seemingly similar
PackageInfo and SMPackage (SMCard today) are still different beasts AND
that we should be careful with introducing more constructs that try to
solve the things *they* already solve. But other abstractions are of
course completely ok. :-)

Or putting it another way - making a competitor to SM or DVS would be in
many ways counterproductive since these tools in some ways work their
magic by turning into de facto standards for the community. Much better
to cooperate on them. :-)

And that is btw one of the reasons I really want opinions on SM. Since a
few important issues were reaised on the list recently I am in the
process of writing down how SM1.1 will work on:

http://anakin.bluefish.se/gohu/15

NOTE that it is a document in progress - I haven't folded in the
thoughts from the recent discussion nor have I described my own plans in
detail yet.
 
> Daniel

regards, Göran