[Modules] Culling the discussion!

Göran Hultgren gohu at rocketmail.com
Fri Aug 17 10:12:47 UTC 2001


Hi!

The discussion is... intense. A lot of questions and ideas. I started this little "culling" of
what we have sofar. And yes, I have missed a ton of stuff - but perhaps you all could take a short
moment to fill in the holes. Try to keep personal views out of the list - I have a bunch of
personal notes in there right now but I will remove them when I post this list again shortly.

So, if people could reply with additions and corrections I will digest them into the list and
regularly repost the list when there have been more than say... 8 additions/corrections. Don't
bother to edit the list itself - I will do that thus ensuring consistency - just post the
"patches"!

And BTW - please, please, PLEASE - remember to cc all these [Modules]-postings to
modsqueak at bluefish.se. I have noted that a few of you forget to do that, especially in your
replies to others.

regards, Göran

A groping-in-the-dark-summary-inventory-call-it-what-you-want-but-its-a-start
-----------------------------------------------------------------------------

Culled stuff sofar from the discussion:

- We do not want to give up the advantages of the current monolithic image. We do not want to
place a too hard burden on the "sunday hacker".

- We want to be able to work connected with repositories in a multideveloper fashion OR be able to
work on a single machine almost as we do now.

- We want to be able to release Squeak as a complete image like we do today OR to release it
modularized with one or more kernels that can suck in different configurations etc from the
repository - or in some binary form like Segments - or something like that. The point is that we
want to have it "both ways" in some form.

- A repository should be able to be kept "locally" in your own filesystem OR use a more advanced
backend - just like ModSqueak in StableSqueak can today, thus supporting the "lone sunday hacker"
or the "multideveloper team".

- If we have well defined modules shrinking/deployment will become an almost trivial process.

- Stephen is proposing some form of scheme for version coexistence where you can make
extensions/changes to modules that are only visible in YOUR module. Or something like that. That
thread has become rather technical and Andreas Raab has been arguing over how it can be done - but
not over if it would be a good thing. (Stephen - perhaps you could revise this? I am not exactly
sure what this is... :-)

- We have acknowledged that the "modules issue" have a whole range of different areas where Allen
wants us to keep in mind to separate "components" from "modules"

- The area of modules is so big that some people are arguing that we will not make ANY progress if
we keep talking about the whole enchilada. Better to take small steps and start by finding the
FIRST step. The core stuff that we can agree on "for starters".

- We will wait with the discussion on different repository backends. It is interesting but we
should be able to have different ones anyway so the question is not high priority.

- Allen made a chart of how we could attack "modules" in three steps (modules, versions,
configurations):
	"It's quite possible (and I would argue desirable) to design module 
	structure, version management, and configuration management in phases and 
	layers.  Start with a module specification that describe program structure. 
	(could be stored in a file or image or where ever). Upon that layer a 
	versioning scheme for identifying revisions of modules. (could be encoded 
	file names, or CVS, or a RDMS, in image, etc.Multiple alternatives are 
	fine).  Finally, add a configuration layer for making sure you are using 
	the correct versions.)"

Personal note that I will remove:
Note though that Joseph's work unifies (if I remember correctly) a few of these concepts so to
believe that ModSqueak only addresses the first step (modules) in this 3-step model is probably
wrong. Again - we do need to produce a good presentation of ModSqueak! Joseph has already put down
so very much thought into that (with code that works to back it up) it would seem pretty darn
STUPID to not take a good look at it first. I would consider this "review" of ModSqueak as baby
step #1 that we need to take.

- Les chimed in regarding modularizing the effort itself:
	"Regarding the Modularization of the Modularization effort itself:  To me 
	it seems that there are three primary efforts that could be going on in 
	parrellel.  These are: Source Code Configuration & Management ( eg: 
	CVST, and ModSqueak's repository ), Conflict resolution ( Collage's 
	Layers ), and finally The Target ( where the classes and methods will 
	live ). The Target is what you would normally think of as being 
	Smalltalk.  I am using "Target" for now, rather than "Module", for a reason."

Personal note that I will remove:
This seems to be a different partitioning than Allen talked about. This is on a higher scale - the
helicopter view! I would guess Allens three different layers deal with the first two efforts that
Les outlines. I also note that again - ModSqueak might deal with more than we are aware of (again
noting the need for a good review of ModSqueak), I believe for example that it has mechanisms for
dealing with configurations of modules and conflict resolution within those configurations - but I
might be wrong.

- Henrik and others have taken a look at Environments which Dan is the father of. I am not quite
sure what the current status on that is.

- Andrew Black wrote in about keeping a super-repository (think CPAN or something like that) for
everything and the virtues of having such a repository.

Personal note that I will remove:
A catalog of modules and a repository of modules does not really need to be the same. Freshmeat
for example is a catalog and does not hold the resources themselves. I would favour the separation
but call for the estabishment of a central catalog. Perhaps Collage is a good candidate - what do
I know! :-)

- There are some very good postings on http://swiki.squeakfoundation.org/squeakfoundation/29.

- Göran wanted people to post their intentions and abilities to work on all this, I start this
list of offerings by stating my own intentions (post yours and I will add them here):
          - Göran: Will focus on integrating the CVS protocol into ModSqueak. Will try to write an
article on ModSqueak, but can not promise anything too soon. Will be custodian of this "culling
list".


Please post "patches" as you see fit!

regards, Göran

=====
Göran Hultgren, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
"Department of Redundancy department." -- ThinkGeek

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/




More information about the Squeak-dev mailing list