RE: Stewards and Squeak Packages

On Fri, 2003-03-07 at 09:33, [email protected] wrote:
> Cees may of course have good arguments backing it up - but why do we
> need to separate what Martin (and I) would like to call "core" into
> "core" and "base"?
> 
Of course I have. Extremely good arguments. And I completely, totally,
and utterly fail to understand that I haven't convinced you yet ;-).

'kernel', 'core' and 'base' are three logical levels of Squeakness, and
I think that if the 'official' distributions distinguish these levels we
have a useful triad of starting point for alternative distributions.
Some arguments:

1. It's a triad. Three is a holy number. That's Good[TM] :-).

2. 'kernel' is the absolutely minimal starting point for anyone to do
anything with Squeak (the VM plus enough code to do a fileIn, including
some no-brainers like numbers, collections). Like an OS kernel, it knows
how to bootstrap itself to higher levels (where a Unix kernel bootstraps
to the point where it can execute '/sbin/init', I think it is logical to
have a Squeak kernel bootstrap to the point where it can file in the
first command line argument and execute the preamble/postamble). 

It is not really useful for most people as a stand-alone distribution,
but helps
a) to focus the attention of people who want to work on the kernel;
b) to aid people who *do* think they have an application for it. Compare
it to the various Linux single-floppy distros: for 99.95% of the Linux
users, the fact that you can download and compile a single kernel is
useless, but it is immensely helpful for these people.
c) prevent forking in the case that groups want to branch out, like
Squeak-E. If Squeak-E (for example) needs kernel patches, this can be
discussed in a small and concentrated forum; the scope of the changes
can be discussed much better if you know what the overall API is the
kernel offers. Squeak-E is currently dormant just because of the
dauntingness of the task; a 'kernel' to look at would immensely help
this and similar efforts.

3. 'core' is the absolutely minimal starting point for 'Squeak as a
development environment'. It is the 'kernel' that has been
'bootstrapped' into an IDE - you get a GUI (MVC? Morphic?), class
browser (Regular browser? RB?). For developers, this might be a useful
starting point - there's a minimal amount of clutter, and you can start
hacking right away. A good analogy is the image that VisualWorks
provides: it opens with transcript, (refactoring) browser; it lacks some
'advanced' tools like StORE (because people want to use CVSt, or ENVY,
Cincom isn't making this choice for you), but has all that's necessary
to further adorn your dev env (in the VW case, the Parcel Loader; in
Squeak's case, you probably want to include the SqueakMap browser).

4. 'base' is the starting point for end users. It's probably very close
to Squeak-as-we-know-it-now. Compare it with installing the average
end-user-focused Linux distribution's 'workstation' configuration; you
get some web browser, a mail reader, ... - all arbitrary choices made
for you by a third party, but good enough to get started. It is a
canonical set of user-directed tools (and quite likely it'll be a strict
superset of 'core' so you get all the development stuff thrown in for
free), which basically says "this gets you going, the tools in here are
maybe not *exactly* what you want, but we've tested them and think they
are good enough for you to be able to work with them". Then, as a user
progresses, he/she will find that FooBrowser is a better package than
BarBrowser if you want to browse a lot of javascript-intensive sites, so
two button clicks later, FooBrowser is kicked out and BarBrowser is
loaded from SqueakMap.

Now, how's that for an excellent set of arguments.

Of course, the *exact* borders between the three levels are largely
fractal in nature - as you zoom in, you get more and more stuff to
discuss ;-). Magnitude might belong in the Kernel, but all methods
currently in Magnitude? Probably not. However, the issue is not whether
we can at this point in time establish sharp borders - we can not and we
will never be able to do so, that's the nature of our environment.
That's why we seem to be so good at discussing it and then deciding upon
it, and that is what we'll have to do many, many times. 

The issue is that I think that this is a very minimal set of, let's call
it, 'blessed configurations' of Squeak that caters to the maximal number
of uses. Leave 'kernel' out, and you don't have anything for people that
want to drive network switches or unmanned subs with it. Leave 'core'
out, and you force e.g. application server developers to either do a
large bootstrap from 'kernel' or start stripping out loads of stuff from
'base'. Leave 'base' out, and most newbies never will take a second look
at Squeak, let alone teachers, etcetera. 

This is the minimal set of configurations that is horizontally targeted.
I cannot prove it, but I think it makes a lot of sense.

Of course, I do hope that we'll continue to have vertically targeted
configurations:
- Squeakland configuration, optimized for education;
- Plugin configuration, optimized for Flash-like things;
- Webdev configuration, with Comanche+Seaside and other goodies
preloaded;
- Darkside configuration, geared to managers (presentation package and a
mind-numbing game like Solitaire);
- whatever.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+aHsU8wOTf+CYnosRAguVAJ9SPssM5rnA3gK2R5BmYLK65o889QCeJFir
R+R2nQfEnnG5lgiL9Y/W57M=
=Cr7y
-----END PGP SIGNATURE-----