On Tuesday 09 July 2002 08:35, Andreas Raab wrote:
> Yes, having mutltiple versions of the same module would solve some of
> the problems but not all of them. What it basically means is that you
> would be running "an old version inside a new one" which means that
> while you might be able to load the old stuff it (mostly) doesn't
> make use of any of the newer features.

But this is an important detail in practice - one reason why Win2000 
runs better than previous attempts is that they now allow old and new 
DLLs to live side by side. Or is that in XP?

> Now for some of these things
> (like more regular applications) this really doesn't matter but for
> others it will. In particular when you are trying to use some older
> version of a module with something that requires a newer version of
> it.

Why would you do that? I am supposing a module at least know what 
versions of other modules that it needs.

> A good example for this is DirectX which does support "modules"
> (more specifically COM-interfaces) with multiple versions. Just don't
> try to mix an IDirectDraw with an IDirectDrawSurface4 ;-)

If you can only run one version at a time, then there will need to be 
some strict control. If you can have more than one then I see no reason 
why the application shouldn't automatically fetch the newer one it 
needs since it won't break stuff already using the older version.

> You got a certain point here although you are not answering the
> question about how people find and get to the top-level modules in
> the first place.

Probably a good Swiki would be enough, but I would rather have something 
more structured and automatically organized like Source Forge.

> It's true that modules may (hopefully will) help
> with structuring stuff at the level below but without finding cool
> stuff first noone is ever going to be in the situation that you'll be
> using any of the support modules ;-)

Exactly. I didn't mention it because modules themselves don't help with 
this, as you had said. We have more than enough technology for this, as 
can be seen in squeakland.org and BSS. This is more an issue for the 
"what should squeak.org look like".

BTW, though I mentioned that non top level modules might be found by 
hard coding URLs or via a simple directory, I would like a system like 
http://www.jxta.org/ even more. Don't have the module you need in your 
running image? Ask your peers!

> > That is just it: you would no longer have to have "the
> > standard".
>
> True and false. True in such that you might not "have to have" a
> standard. False in such that there always will be one. Or would you
> want people to set up their own window colors, frames, button
> preferences, key mappings before they can even start doing things?!
> ;-)

I would like for the download page to have a gallery of options like in 
http://minnow.cc.gatech.edu/squeak/683 and when you click on one you 
will download the top level module needed to make Squeak look like 
that.

> > 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.
>
> But that's wrong. Given (for example) Jim's Zurgle stuff in the image
> you won't need modules to have your skins. What's needed for that is
> parametrization not modularity.

True: this customization could be in the form of a small external file. 
But we all know its format would grow more and more complex until we 
would need to allow code in it to get all the things we want done. At 
that point it would really be a changeset, and from there to a full 
module would be a small step.

I should have made my assumptions in this discussion explicit: I was 
thinking about the case when you have the VM and just enough stuff in 
the basic image to be able to load modules. That plus a reference to 
some top level module you want (an application) would load everything 
needed to run it. Then the initial "Welcome to Squeak!" screen would be 
just another application. It would not be in the basic image. Some 
other Smalltalks are like this.

-- Jecel