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