[Webteam] Notes on Altitude in box3

[Chris Cunnington]

I deployed Altitude in box3 on Thursday. It's Wednesday so that's almost 
a week.

There's good news and bad news on that front.

The look of the site itself is not an important consideration in this 
discussion, I don't think. It has the content of squeak.org, which is 
links. Changing it to what it needs to look like is trivial. The problem 
with the design of the site is agreeing on what people want, which is a 
pain, because people don't know what they want, they just know they 
don't like what they're looking at. So, the initial impression of the 
sight I'm not about to trouble myself over too much, until people have 
some idea of what a "Squeak homepage" is supposed to look at.

The good news about Altitude is, in my opinion, that it is the fastest 
web framework every to be deployed in a Smalltalk image. The bad news is 
that at the moment it isn't 100% stable. I've killed and restarted the 
process twice.

If you try the site at http://173.246.101.237:8624 you'll see it moves 
at the rate of a laser beam. Go to Smalltalk Hub and compare. 
http://smalltalkhub.com/ Or 
http://www.esug.org/wiki/pier/Conferences/2012 (Wait for how long it 
takes for the browser to stop spinning.) So, Altitude is dead fast.

It has a problem though. On Monday I checked the site and Chrome said it 
could not be reached. I hit the ip and port. Nope. I logged in and top 
-d 1 to see it is now consuming 99% of CPU. Not good. I killed the 
process. I just did it again this morning the day after. There is no 
debug log printed into the image directory. So there is nothing to check.

Now, I think I can tell you how to reproduce the problem in localhost 
reliably. Build a site with Altitude. Make an intentional mistake.

Say you want a break tag in your page. You type in html b, when what you 
should have typed is html br. The basic checker will not see a syntax 
error, because there is an existing b tag in the canvas. But really, 
it's gibberish. Go to your browser and press refresh to see what you've 
changed. You get an error. Here's the important part.

The browser is still spinning. If you touch the debugger window while 
it's still spinning, then your image will hang, It'll start consuming 
99% of CPU. You'll have to break out the Activity Monitor and kill. 
Guess what? You're work is now lost. Do that three times in a row and 
your mood will start to change. As a preventative measure, I started 
saving the image every time I was about to refresh the browser.

But here's the thing. If you stop the browser spinning, stop it from 
requesting the server, then you can use the debugger window without 
incident. I think this is related to the problem I see in box3. And I 
think it has something to do with Altitude/Xtreams not knowing when to 
stop.

Kom, however weird, is very stable. WebClient, more pleasant, is after 
two years seen as a stable server. It's the reliability of the server 
that matters, not the application, so much. And what happens when you 
type a wrong tag into GreenNeon, HTTPView2, or Seaside?

First of all it doesn't crash. Second, it prints a walkback in the 
browser, which is very useful. (I take it that the server gets output 
from Exception description and routes it to the browser.)

WebClient assumes a difference between server and application. I think 
that perhaps Altitude has see more effort spent in creating the 
application than ensuring the server is as reliable as it needs to be. 
Or giving a developer the kind of feedback expected in seeing a walkback 
in the browser. But, my God, it is so fast. The fastest.

I am certain of two things. The first is that we cannot watch to reboot 
squeak.org each day. The second is that I have every confidence that 
with a little work Altitude can be hardened so that it doesn't crash. 
This is, after all, the first time Altitude has every been deployed in a 
server. I think having the fastest framework is worth the effort.

Chris