More Modules brainstorming:

How about generalizing the concept of the official, gamma and alpha
streams?

Let me explain: In Debian I think they have "rules" describing when a
package goes down into testing and when it finally goes into stable. For
example, I think that a package needs a certain time in unstable without
having any bugs reported against it and then it will automatically enter
testing.

So... could we do the same for Squeak but - of course - go a bit
further? :-)

My idea is to generalize all these aspects into a subscription system
where the user define the rules for what modules she wants to enter into
her system?

I am visualizing a future where our modules system has grown and become
distributed (see my earlier post regarding module forwarders) and where
different module maintainers publish their own updated module versions
for their modules.

The only thing separating say Scott Crosby's #(Squeak People ScottCrosby
FullTextIndexing) module from the #(Squeak Language Collections) module
would be metainformation like perhaps a set of keywords describing the
nature of the module. For example, SqF would probably "bless" modules to
be "SQUEAK OFFICIAL CORE" modules. And say, Celeste should probably not
be tagged like that - Celeste is an application and just being in the
image today doesn't mean it should be blessed as "CORE". But they are
both still modules.

Anyway, so all modules in the Squeak universe are stored in a big
hierarchical virtual filesystem comprised concretely by many FTP/HTTP
servers (hopefully glued to each other by my forwarders). How do you
then get yourself an image with what YOU want? How do you get an
official SqF image for example?

Imagine that you just download a very small (as small as we can make it)
bootstrap image together with a chosen textfile (no UI available in the
bootstrap) containing rules for your module subscriptions - a
subscription profile. SqF could have a few of these subscription
profiles premade with suitable rules depending on the user. Say a
developer profile, an etoy user profile etc. The bootstrap could even be
fed an url and fetch the profile.

The bootstrap image is started and loads the chosen profile. It then
proceeds to load modules (from the net or locally from the cache just as
Henrik has built it) into the image. Voíla, an image. Then later you
should be able to just select "update" and it would go through the rules
again and load any modules it decides to load.

Now, how do we find the metadata about all available modules in the
universe? Debian has index-files stored on a few top level ftp/http
servers which are simply downloaded and aggregated into a database.
Gentoo (another very interesting Linux distribution) has a filetree with
metafiles that you simply rsync (download) to your local machine. Both
are simple schemes but they do require a hefty download when it get's
large. But of course - it's a simple start.

So, first the bootstrap image needs to download metainformation about
all available modules in the Squeak universe. Let's say it does this by
simply downloading a compressed XML file from a central catalogue server
at SqF. That would do nicely to start with. We don't have that many
modules yet and with compression it will be very small.

Ok then, what next. The rules in the profile can now, based on the
metainformation loaded, select what modules and what versions of these
modules it wants to load.

Let's say that we start with a few simple rules, enough to capture the
concepts we have today (alpha, beta, gamma, official whatever), rules
should of course be expressed in Squeak.

[Someone interested - insert imaginatory sample profile here! :-)]

Ok, now let's look into the future beyond. If the metainformation about
the modules also included information like:

1. The bugs reported on module (last date of reported bug, severity of
outstanding bugs etc)
2. Lifecycle of module (time since publish of version)
3. Major/minor update ("size" of update, was it just a bugfix release?
Or a major revision?)

Given these things we could actually define rules for the alpha, beta,
gamma streams themselves and we wouldn't need to bother about them
anymore. If a user wants to play it really safe (think Debian stable -
safe bordering to paranoid) she just (this is an example) selects a
subscription profile published by SqF called "SQUEAK PARANOID USER" with
rules that only selects modules that are for "users" and also only loads
modules which haven't had bugs reported on them for 3 months and with
time since publish no less than 6 months.

Ok, finally - just to end with a twist - these "subscription profiles"
could actually be classes published in the Modules system. I could then
access them just like modules - #(Org SqF SubscriptionProfiles
SqueakParanoidUser) and actually feed my bootstrap image with that path
instead of a textfile. Of course. :-) :-) {Head starts spinning here,
insert sound effect}

Braindump ends.

regards, Göran

PS. I actually find these ideas rather appealing, we could start by
whipping up the catalogue server. First step for that would be to define
a sortof "LSM" (an old metafile format for Linux software) for Squeak
modules. I have a minimal proposal that I will post soon. DS