On Monday 08 July 2002 20:32, Andreas Raab wrote:
> I didn't want to write this message before but I think it's time to
> take an illusion from all of you. I have the impression that a
> majority of people on this list believes that modules will solve "all
> the problems of Squeak". This is wrong on many (if not all) accounts.

I think they could solve some of the problems you mention below.

> Point #1: I presume that being "trampled upon" means that things keep
> changing rapidly under your feet. Modules will not solve that
> problem. They will not because we will still maintain an incremental
> update cycle. If you were using stock-releases then *nothing* has
> changed since the last release. With modules things will *still* keep
> changing between releases. Or do you realistically expect that we
> won't change anything anymore just because now they're in a module?

This is true for a design which doesn't allow multiple versions of a 
given module to be loaded at the same time, which seems to be the case 
for the current effort.

With multiple versions you could have an application using a tried and 
true module from an old release and another application using all the 
latest updates.

> Point #2: Modules will not solve the problem of integration. If you
> expect that it's easy for you to make some module and it will
> automatically work for the next ten generations of Squeak then
> re-read point #1. Committment is required, you cannot stand off and
> say "because I made this a module it's going to work forever" (this
> is a point of view that I see implicit in many opinions voiced about
> the module system).

You are right again. Without multiple versions this will have to be 
handled manually.

> True, modules will help to *identify* existing
> and potential problems but someone will still have to review them and
> fix things as appropriate. Personally, I have the impression that at
> least some people think that having modules means handing things of
> to some central authority, which will then do the maintenance and
> integration work from there on. E.g., basically handing off "the
> module" and never again worry about it. This is wrong, both
> conceptually and practically. If you need an example, come over to
> the SqModules mailing list and see how at times we are wondering how
> things "were planned to work".

I think that anyone who has tried to use module tools in Linux can 
easily see how much effort goes into keeping things working. Even with 
something like Synaptic to help me, I still waste a lot of time getting 
things working on my system because of all the little mistakes (module 
updates file, but not symbolic link, for examples) people make.

> Point #3: Modules will not solve the problem of what is in the "base
> image" and how to find things that are not in. What is needed is a
> community place which is generally accepted as a source code
> repository, a place both well-populated and well-maintained, with
> people presenting their work or that of others. Some newsletter for
> example, which a person with writing skills could set up to inform
> the community about ongoing developments. Some good soul collecting
> cool, interesting or just fun stuff and have it ready at a single
> click. This issue is entirely unrelated to modules (and in fact, one
> of the things that I proposed to SqF for raising the visibility of
> itself).

Well, this is the case for "top level" modules. The problem is when you 
are trying to load something that requires lots of other stuff to work. 
In that case we want something more like "apt-get" than "findRPM". Some 
module name to URL directory would be great. We don't care what all 
that stuff does, who wrote it and so on.

Of course, whoever created the top level module we are after did need to 
find out what support level modules were out there, what they did and 
how to use them. So there are two different interfaces for downloadable 
things and modules (directly by encoding the URLs of modules they need 
or indirectly via some directory) can help with one of them.

> Point #4: Modules will not solve the problem of what "the default
> experience" should be. While it may make it easier to have a variety
> of looks and content someone still has to make the ultimate decision
> about what the standard should be like. Most people never change the
> defaults so that decision is important and has to be made very
> carefully. Modules don't help the least bit to actually make that
> decision.

That is just it: you would no longer have to have "the standard". Right 
now, to make available for download several alternative "out of the box 
experiences" you would have to have a directory with a lot of 20MB 
files. Which wouldn't be a problem except all of these would have to be 
updated every few days.

With modules you could have a set of common files adding up to roughly 
20MB plus a lot of very small files with the different "skins". The 
frequent updates would only affect a few files (possibly just one) at a 
time.

> With all that said, I still think it's crucial to get the module
> system off the ground, and if you have a bit of spare hacking time
> then *please* come over to SqModules and help us. But just don't
> expect unreasonable results from that work.

My own design is far too radical for Squeak, I think. I would love it if 
we could share this work, but I really do need versions and integration 
with memory management (for those who haven't seen it, it is at 
http://www.merlintec.com:8080/software/8 and for those who have it 
hasn't changed recently).

I started out writing this to contradict you but ended up mostly 
agreeing.

-- Jecel