[Squeakfoundation]An architecture for sustainable Squeaking

[Henrik Gedenryd]

My idea is that we need a simple but powerful overall principle of
organization.

(According to this proposal) we should adopt a variant of the well-known
"layered" or "onion-skin" architecture, along with a principle that ensures
sustainability:

(1) Architectural law: Modules may only depend on (use code in) modules
"further in"/closer to the core. (Outward dependencies are forbidden.<*>
Dependencies should be made explicit.)

(2) Principle of sustainability: In a sustainable system, the more central =
a
module is, the less volatile and more conservative it needs to be.

That's all, technically, and these are not fascist laws but mere natural
necessities.


Comments:

Obviously, closer to the core are more essential things. Outermost would be
"applications" that are entirely optional.

The further out, the more you can do what you want (because the less others
depend on you), but also the more work for you to adapt to changes in the
inner layers. (But these should also change less.)

As code moves inwards, it gains importance, grows in value for others, but
also takes on responsibilities.

The closer to the core:
- The more the quality, stability, etc. of Squeak depends on it (Squeak: th=
e
program, the community, all the uses of Squeak)
- The more sensitive the contents
- The slower should code change. Use maximum foresight. Not haque du jour.
- The higher standards should be imposed on changes (bug fixes yes, good
code a must, "good to have" additions & quick toss-ins nope, code that
doesn't belong there--no way Jos=E9)
- The more a module needs to be the "joint responsibility" of Squeak

Outermost would be Applications, which:
- literally noone else depends on
- are free do whatever they wish,
- but are the sole responsibility of their authors to maintain


There is no longer any sharp line for what goes "into" Squeak here. This is
very different from today's either-or-image situation.

(*) This means no more "String asUrl", because this makes the core module
with String depend on the much less vital module PWS or whatever, so you
have to load PWS to use strings. _Maybe_ we need to allow outer layers to
add code in inner-layer-classes, but this creates spurious sideways
interactions between modules. Perhaps only applications should be allowed t=
o
do this.

Pieces like Celeste the mail reader app would most likely become
multi-layered, with the UI outermost, and more generally useful code in
separate, more inward layers--e.g. code for sending e-mail, which may be
useful in many other contexts, notably for posting code to a list or so.

There should be code that can validate that a (new) piece of code doesn't
violate these rules, to automate things.

There would need to be separate update streams for each module (and updatin=
g
mechanisms would need to be provided by the system as well). You choose
which ones you want.

Up to today if you want the essential bug fixes you will get SqC's latest
experimental code tossed in for free. And if you opt not to be an alpha
pilot then basically you won't benefit from the community any longer (in
effect you do the f-word). This ain't a good situation.

Note that many of SqC's experiments would become "far-out" layers (how
appropriate). Or rather, SqC would need to divide their stuff into layers o=
f
well-behavedness too, if they want to contribute to the official system, so
to speak. Otherwise the stuff would remain as applications.

This will be extra work for them and I don't know if they will want to do
that. It would make SqC have to play by the same rules as everyone else,
essentially. This is the part that I have been uncertain about whether it
will happen, but I think this is necessary. We are at the point where
pioneer town X needs to start collecting taxes and erecting law and order i=
n
order to keep growing. Well you've all played SimCity so you know.

Henrik