Are you familiar with the about to be launched Stable
Squeak World Tour? We will have our first gathering in
Southampton, UK next weekend. This will coincide with
the ESUG summer school. The URL follows.
http://wiki.cs.uiuc.edu/CampSmalltalk/Squeak+World+Tour

The goal is to apply "pink" plane values to Squeak
development. We are not looking to add functionality
to Squeak, but rather to establish a minimal base,
refactor code as necessary to allow the modular loading
of functional subsystems like Morphic, Wonderlands, etc.
These are the values of production code rather than
those of the paradigm shifting "blue" plane. Ideally
we would like to stay on the line where these two planes
intersect... (if I recall Koestler's book included a
nice diagram of the magical conceptual place where these
planes coincide... but I digress)

The goal is to have a self organized group of Squeakers
who value systems that are minimal, may be reliably rebuilt
from sources, that have libraries of composable modules
and is lacking references to undeclared entities. If we
are careful, we should be able to feed our base refactorings
back into the Squeak update stream. We will be basing off
the Squeak 2.8 release.

[:tourGuide|StableSqueak tourGuide] JohnSarkela :-}>

-----Original Message-----
From: Paul Fernhout [mailto:pdfernhout at kurtz-fernhout.com]
Sent: Friday, August 25, 2000 6:41 AM
To: squeak at cs.uiuc.edu
Subject: Re: Update server for non-updates?


Hans-Martin-

Interesting reading at: http://squeak.heeg.de/

I think what you and others want to do makes a lot of sense for the
Squeak community. It ties in with issues of modularity and managing
complexity -- central issues in any substantial effort.

As the ultimate extension of this concept, I would love to see a minimal
Squeak core maintained as the "official version" (mostly with just
TCP/IP support and file support and some part of something like SCAN)
that could go out and load for example the desired version of Morphic
into itself, along with the BitBlit plugins etc. needed to support that.
I've heard of some version of Linux that does that -- boot from a
floppy, and it can load most of itself off the net.

My biggest comment on your specific outline would be on the issue of
"ownership" for development in a broad ranging open source context like
Squeak (as opposed to say a corporate setting). ENVY with security has
the sort of "everything is owned by one person" ownership model, and in
practice even in a restricted corporate setting it is always
circumvented on projects (at least ones I've been on). "Owners" go on
vacation, are in meetings, are too busy, leave the company, etc. I think
the idea of "responsibility" in a distributed evolving system is a very
complex topic and requires probably a very flexible solution.

What I see eventually happening is a more of a "peer-to-peer" component
sharing system, where some "peers" act as popular servers for software
components and other things, but the sharability of data via a sort of
email-like means (request/response or also push on a channel) is woven
throughout the system (probably along with a directory service similar
to how one goes to an HTML page and selects things to download). I'm
very interested in repositories, but I see them in the end as local --
part of a distributed network. When you have local repositories of data,
the issue of "ownership" and contacting someone for permission to make
new versions doesn't feel appropriate to me. In this scenario, something
like SCAN client and server software is built into each Squeak system by
default. Some people will share more data than others (just like now).
Probably most people will only ever share some parts of their repository
with selected others during the course of a specific project (to enable
team programming).

You might also wish to look at work inspired by Doug Englebart:
  http://www.bootstrap.org/alliance-980.htm

And endless discussion on these topics (some by me) with tons of great
links to other projects currently underway:
  http://www.bootstrap.org/dkr/discussion/

Activities similar to the ones Doug Englebart proposes in his "OHS"
system are the sort of thing I would really love to use Squeak for.

And of course, you might consider using the Squeak version of the
Pointrel Data Repository System I wrote as part of the substrate:
  http://sourceforge.net/projects/pointrel/
(I have a somewhat improved version from that wiht limited transactions
-- although it would be even better if Squeak could truncate files). 

By the way, you might also find this essay called "The Rise of 'Worse is
Better'" of interest:
  http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html
Common Lisp developers use it to explain why C/Unix took over instead of
Common Lisp (or Smalltalk :-) .  What your are concerned about is the
potential application of this concept regarding a Squeak code archive.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Hans-Martin Mosner wrote:
> 
> Well, exactly such a thing is what I have started in my SCAN project.
> Look at http://squeak.heeg.de/ for some information. Basically, I want
> to build a repository that stores versioned software components and
> more, using digital signatures for authentication and integrity
> checking. Much of it already exists on my Powerbook and will eventually
> run on that squeak.heeg.de machine, but I currently have too little time
> because I'm working full time in a customer project and have little
> spare time to spend on SCAN.
> I do think that my ideas on a repository are well thought out and will
> provide a much better substrate for sharing and versioning than an
> ad-hoc approach.
> I would be rather disappointed if just a few weeks before I can start to
> work full time on SCAN somebody came across and implemented something in
> a hurry which provides only part of the SCAN functionality, but makes
> introducing SCAN much harder because it's just there first.
> 
> So please, read that stuff at squeak.heeg.de, tell me what you think
> about it, contribute your ideas and criticisms, but just don't rush for
> a solution thats only a half-solution!
> 
> Cheers,
> Hans-Martin