Coopetition in Squeak

An excellent article by Hannes Hirzel. Quoted with permission.

I would like to comment on the trigger word “competition” which Pavel has brought up in connection with Squeak / Etoys / Pharo and Cuis. Andreas is advocating a discussion which actually promotes the work and I support this.

1) There is competition – sure – but as a whole it is just a sign of a healthy eco-system to have Squeak / Etoys / Scratch / Pharo and Cuis around. I have written this earlier this year when we were asked to fill in a questionnaire. In fact as a user of a Squeak based Smalltalk “distribution” or “fork” I am happy that there are alternatives. The use of these alternatives may vary though.

2) It is probably more precise to speak of coopetition.

Coopetition or Co-opetition (sometimes spelled “coopertition” or “co-opertition”) is a neologism coined to describe cooperative competition. Coopetition occurs when companies work together for parts of their business where they do not believe they have competitive advantage and where they believe they can share common costs.

Or maybe we should speak of a ‘distributed’ development approach or just having different distributions which share ideas / concepts / strategies / code snippets and packages. This is reuse on all levels (analysis, design, implementation, package, methods). A recent example is the WebClient and the release announcment of Pharo 1.1 for example states (http://www.pharo-project.org/pharo-download/release-1-1).

StandardFilestream now performs read-buffering, dramatically speeding up some operations like “Object compileAll” (2x improvement) as well as various other operations (scanning change lists etc). This change was taken from Squeak.

and further down

A new general cleanup protocol has been added. The cleanUp protocol takes an optional argument to indicate whether we’re doing an aggressive cleanup (which involves deleting projects, change sets, and possibly other destructive actions) or a more gentle cleanup that’s only supposed to clean out transient caches. This change was taken from Squeak.

3) Squeak, Etoys, Pharo, Scratch and Cuis have different “missions” so to say. Or we could say “different customer groups”.

As a reminder for the goals of Squeak I would like to mention the article “Personal Dynamic Media” written in 1977 which is to be found on http://www.scribd.com/doc/454106/Personal-Dynamic-Media. It is amazing what was there at that time.

The problem in the past was that Squeak development did not scale in terms of developers working together and going for forks was the only reasonable thing to do at that time. But this does not mean that new approaches are not feasible. Scratch so to say was ‘silent’ fork. And at the same time a very successful one. It did not create much noise on this list. Maybe we should call it an application. In the area of Squeak these borders are blurred (intentionally) and this might be part of the causes for these kinds of discussions.

4) Going for a minimal kernel with loadable packages maintained by various people is actually meant to stimulate “competition”. People will be encouraged to take the minimal kernel and load all kinds of things on it and distribute the result and create communities around it.

5) For this to work the kernel has to be minimal in a sense that it can be managed by a small team. This is the aspect Cuis strongly promotes and we want to adapt for Squeak. Actually this is not new at all. It has been a long standing goal. But for many reasons about which we have pondered many times it had not been achieved so far. Juan has given the real-life proof that it is possible to maintain his own fork as a single person while at the same time adapting important changes from elsewhere. In addition he has contributed back to the main-line Squeak development. From this point of view we should really de-emphasise the negative aspects of competition.

6) This time we have Andreas, Pavel and Juan for the core, Eliot on the VM side and Bert for the Etoys link working together. Others are working on various aspects improving the system. I think this is an opportunity and there is a real chance of success.

7) As an illustration I did a sketch. (see attached PNG file). I think the overlap of the distributions is considerable. As a follow up it would be nice to have some simple statistics like no. of classes per distribution. Number of classes with identical names across distributions. As the picture is very rough somebody might post a more accurate one.

Squeak, Etroys, Pharo, Cuis

Cheers

Hannes

P.S. Please note that in the meeting report this thread is about Randal says that he wants to contact the other Squeak based projects to talk about a minimal core.

Advertisement

New Teleplace Server Release

We just finalized the release of the Teleplace Enterprise Server 3.5 which is our first product release based on Squeak 4.1. The process of moving our code base from the (3.8 based) Croquet images to Squeak 4.1 had been ongoing for a while by me posting most of our internal patches to the base system into the trunk during 4.1 development. Once this was done we were basically ready to switch but due to the potential risks of such a fundamental change the switch didn’t happen until after the Teleplace 3.5 client release went out.

For those of you interested in the details, our base images are “moderately shrunk” versions of Squeak 4.1, meaning that we’ve unloaded many packages that we have no need for (incl. Traits, Etoys, Protocols, SqueakMap, Universes etc) but keep some (like MVC) that for historical reasons other packages depend on, and others (the various Tests packages) that have high value for a relatively small footprint. Our typical base image starts around 10MB, after we’ve loaded all of our development packages it goes up to some 27MB and when it’s been readied for deployment (which removes unnecessary fonts and trims the MC ancestry) it’s at 17MB total. Needless to say, all of this is powered by Cog.

Oh, and in case you were wondering why I’ve been somewhat quiet recently: Not only did we just finish a release, we also have a new CEO. Either one alone would keep me busy, having both at the same time is … a bit overkill 🙂 Hopefully I’ll find some more time to spend on Squeak soon.

Using SqueakSSL with Seaside

Update: I have included instructions for Pharo along the way.
Update: There is now a separate post with Windows instructions.

With the SqueakSSL work progressing nicely, it’s time to look at having it integrated with Seaside so here is a quick tutorial about how to get SqueakSSL going with Seaside 3.0. The integration is pretty straightforward, but the setup can be a bit daunting since there are several pieces to it. Let’s get started:

Step 1: Download Squeak 4.1 and Seaside 3.0rc
First off, we’re going to use Squeak 4.1 with Seaside 3.0rc on Ubuntu (since this is the only tested server configuration at this point). To download Squeak 4.1 with Seaside 3.0rc fetch the Seaside 3.0 Easy-Install from Squeak.org. Unzip the contents into a place of your choice and make sure you can run Seaside by cd-ing into the “Seaside 3.0.app” directory and launching “./squeak.sh”. This should bring up the Welcome screen shown here:

Seaside Welcome Screen

If you want to use Pharo you should fetch the Seaside OneClick image from the Seaside web site.

Step 2: Download and install the SqueakSSL plugin
Download the binary version of the plugin and extract it. Copy the plugin from “SqueakSSL-bin/unix/so.SqueakSSL” into the directory “Seaside 3.0.app/Contents/Linux-i686/lib/squeak/4.0.3-2202”. The plugin (so.SqueakSSL) should now be next to many other plugins in the same directory all called “so.XXX”.

Step 3: Install SqueakSSL and WebClient
Next, go back to your Seaside image, open a workspace and in the workspace evaluate the following code to install SqueakSSL and WebClient:

(Installer ss)
	project: 'SqueakSSL';
		install: 'SqueakSSL-Core';
		install: 'SqueakSSL-Tests';
	project: 'WebClient';
		install: 'WebClient-Core';
		install: 'WebClient-Tests';
		install: 'WebClient-Seaside'.

For Pharo users, you need an additional package (WebClient-Pharo) and you’ll want to use Gofer, like here:

(Gofer new)
	squeaksource: 'SqueakSSL';
		package: 'SqueakSSL-Core';
		package: 'SqueakSSL-Tests';
	squeaksource: 'WebClient';
		package: 'WebClient-Core';
		package: 'WebClient-Tests';
		package: 'WebClient-Pharo';
		package: 'WebClient-Seaside';
	load.

Step 4: Setting up Seaside
First thing, make sure you close the existing Seaside Control Panel and open a new one via world menu, “open…”, “Seaside Control Panel”. In the control panel, choose “Add adaptor…” and select “WAWebServerAdaptor” (this should be the last item in this list). Choose port 8443 (or any other convenient port) and accept. Select the adaptor in the control panel and right-click to get the context menu. In the context menu select “Use SSL (https)…” (if you cannot find the menu item, you haven’t closed and reopened the control panel, so go ahead and do that now):

Enabling SqueakSSL in Seaside

SqueakSSL requires a certificate to be used with this instance. Enter the full path to the .pem file which must include both the certificate and the private key. You can create .pem files using the openssl tool chain. Once you’ve entered the certificate path, accept the dialog.

Step 5: Trying it all out
Start the adaptor if you hadn’t done this earlier and point your web browser to https://localhost:8443/ At this point there are several ways in which your browser might react:

• The browser complains that “the connection was reset”. This almost always means that there is some issue with your cert. Check the command line output to see if it says something relevant such as “file not found” or similar.
• The browser complains that “the connection is untrusted”. That means your certificate is either self-signed or it doesn’t match the host name. Both are expected outcomes, you should tell the browser to proceed and add an exception for this site.
• The browser complains that “the page is partially encrypted”. That means some contents on the page is using http instead of https. You should ignore this warning (it’s a bug in the welcome page that should be fixed in Seaside 3.0 final).

But once you’re through with all of these issues you should be able to browse your site like here:

Seaside and SqueakSSL

Congrats! At this point SqueakSSL and Seaside are happily running together. You should be able to browse your site with no restrictions.