[ENH][Modules] Delta Modules [was: Another version]

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Thu Oct 25 14:56:30 UTC 2001


I have read Henrik's response to Allen and we seemed to be in agreement
(which is nice, because that means I seem to understand this! :-) - btw
I wrote that I saw something in the code and that was actually in the
code COMMENTS. Henrik is right in that it probably is not implemented
yet (DMs changing their baseModules external modules).

Awaiting responses on mine and Henrik's answers to Allen I have a
theoretical question to Henrik. While I was sitting getting my haircut
(for an obscene amount of money - should have checked first) I pictured
the following scenario:

Module A is at revision 1.34.
I then work a bit on module A, it isn't finished so I haven't published
it yet and thus it has no revision number.
I start working on module B (so that module B is my "current module").
When I then add a method to a class in module A the system will create a
DM for me and add that to module B.

Question to Henrik: Is this where the system (or I, the developer) needs
to choose what kind of reference to the baseModule that I want to have
in the DM? Clearly the revision of module A that the DM refers to has no
revision number at this time. I guess that the default reference would
be something like "the baseModule is module A" (no revision number
specified) or "the baseModule is module A revision higher than 1.34" or
something else.

Ok. I was writing up some thoughts about projects and updates. I haven't
cleaned it up so there might be mistakes but take it as food for
thought:

Updates
---------

Our current scheme of updates as ChangeSets should in the long run be
incorporated in the modules system instead. Since a Delta module can
describe the difference between two module revisions we could quite
easily collect changes to modules as deltas.

Example:

Dan fixes a bug in SortedCollection. When he decides that he wants to
release this as an update he just drops it as a delta module in the
module Org/SqueakCentral/baseUpdates/SortedCollectionFix3567

Done. Using a numbered serie of updates is probably still a good thing.
He drops an email to the list (or in some other way inform us that there
are new updates available).

I would then just reload the module Org/SqueakCentral/baseUpdates and
Henrik's code would download the pieces that are missing (the new delta
modules that I haven't seen yet) and load them into my image. I could
then take a look before I choose to activate them or whatever.

When Dan decides that the Collection module should be released as a new
revision containing the fix he would do that and... Well, what happens
then... Henrik? Probably we just load the new Collection module and
since the delta we already had loaded was for the older revision it
would be deactivated when the new Collection module revision is
activated.

If we view the module "Org/SqueakCentral/baseUpdates" as a "channel"
module (only convention, not a new type of module or anything) we could
have several of these. For example, there could be a separate one for
Celeste or Morphic and even I could set one up if I wanted to at
"People/gh/SqueakCVS/updates" or whatever.

If we then would like to be able to easily find what modules out there
that are so called "channel" modules (channel module = "module that
someone maintains just containing deltas that will later also be
released as new revisions of the modules in question") we could have a
convention to just list them under the topmodule "Channels".


Projects vs Modules
----------------------

I have read the stuff on the Swiki and my naive view is this:

A Module is a published piece of code. It is not a "binary deliverable".
But you can download/load/activate them in your environment. I think it
is good that they are not binary and I think it would be much harder to
build such a system with the functionality that Henrik have put in there
if they were binary. Being non binary also makes it possible to
manipulate these things more easily. On the other hand the repository is
a pluggable component so that we can have different kinds of
repositorys. For example, we could have a repository implementation that
uses ImageSegments or something to increase loading speed.

A Project is more of a published binary deliverable. It surely can/could
contain one or more modules but it also contains live instances etc. It
is in my eyes analogous to the "binary download" you see everywhere on
the Internet - just click and go. Typically not used by developers when
they need a module to use in their own project but more for Squeak
endusers "surfing for content".


Example:

I write a cool Morphic game including classes for general animation. The
code is composed of a Module representing the Game itself with 2 more
general submodules for Animation and Sound. They are not really blessed
to go into the "base image" so I put everything in "People/gh/CoolGame".
Ok, I upload it all onto the virtual module server (more on that later)
so that people easily can load this module.

But I also set up a Project where I start the Game up with a centered
window and I also type in a todo-list in an open Workspace. Finally I
smack in a nice looking background image and then publish the Project
onto Bobs superswiki AND also to another superswiki in Sweden containing
only Morphic games (just fantasy).

So, developers typically load the module to get to the code and perhaps
reuse my Animation module or just check out how the game was done. End
users typically find the project and loads that - it probably is faster
and they get a "just point and click" experience. They get the modules
with the project, but that is just a bonus.


regards, Göran




More information about the Squeak-dev mailing list