RE: Stewards and Squeak Packages

Hi Cees and all!

Cees de Groot <[email protected]> wrote:
> 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"?
> >=20
> Of course I have. Extremely good arguments. And I completely, totally,
> and utterly fail to understand that I haven't convinced you yet ;-).

I play hard to get, that is all. :-) 

> '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] :-).

Actually a better argument than people may think.

> 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).=20
> 
> 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.

Sounds good. Should we have *one* official kernel and then of course
people can register their own variants on SM?
I think so.

> 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).

So "core" is the baseline that you normally (unless building something
of your own on top of a kernel directly) "know" is there. And it is a
superset of the official "kernel" I assume.

> 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.

Would "base" also be the boundary of everything maintained by stewards?
I mean - does base define what we call "Squeak"? Does it include all of
the stuff that we - as a community - considers to be "ours"?

I would like to have it that way, anyhow. 

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

Yes, I like it and I buy it.

> 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.=20

Of course. But it is good to get at least *something* defined so that we
can enrich our language.
Now - if I say to you that I consider something to belong in base
instead of core - then you will understand what I am talking about.

So, to get practical - should we introduce these three as Categories in
SM? I would think so.
And then of course a fourth is needed - "extra" or "other" or something.
And should this category be mandatory?
Probably. I will wait and see what people say and then we could perhaps
write these categories down. You know, nail the name and a oneline
description plus a URL to a Swiki page that explains it further. (Yep,
each category can actually have a URL associated that explains it in
detail, I have only used it here and there).

And of course, I would like more help in maintaining the SM category
tree. If anyone has ideas I would like to hear them.

> 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

I would rather like to call it "package groups". I think.

> 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.=20
> 
> This is the minimal set of configurations that is horizontally targeted.
> I cannot prove it, but I think it makes a lot of sense.

Agree.

> 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.

Sure, those will arrive when SM goes forward. We need versions in SM
first. :-)

regards, Göran