Lukas is going over the "year in Seaside" - one of the interesting facts is that the average visitor to the site spends 5 minutes there. That's impressive - most sites stay in the seconds.

Another thing he's going over is how they've managed to keep the code portable enough to hit 6 platforms. Lukas is now using Pharo (A Seaside fork). GNU ST is a new player this year. Of course there are ports to Dolphin, Gemstone, and Cincom - and the source of it all, Squeak.

How to on portability (all of this is currently relevant to the 2.9 dev stream)?

• No assignment with underscore
• No Brace or Array constructors
• No Byte Arrays
• No VariableBindings
• No Selection Blocks
• None of the #ifNotNil: or #ifNotNilDo: messages

Pragmas are ok - they don't use them now, but they are possible, They restrict themselves into that syntax. Now, what about libraries?

• No Collection >> #=
• No #withIndexDo:
• No #pairsDo:

Strings - don't pretend that Symbols are a String (not portable). They don't use #match: - too many issues across implementations, and with pseudo-regex syntax. No usage of #asString. Also no usage of #displayString - again, different implementations return different things - thus, Seaside has its own, #toString. No IO, as it varies too widely.

These are all basic - the main thing they rely on is tests. They've created Slime - Lint tests for Seaside. The test coverage is expanding - 3x more tests in 2.9 than 2.8 (thus far).

They aren't using any source exchange frmats. They use Monticello in Squeak, and all the target Smaltalks read from or support Monticello. Merging code back, on the other hand, is harder. While code can be exported, the version history and change trail is lost in conversion. Lukas would be happier if all vendors moved towards supporting Monticello2. The Gemstone guys agree with that.

They don't use Sport - they do have a little library they call "Seaside Platform Support". Bruce asks "Why not Sport?" Lukas more or less says - they don't need all that Sport does, and they want to keep it small.

There's the "Seaside Namespace" - the WA class name prefix. They would like to keep WA within the core of Seaside, and not have vendor or application code use WA.

Their "Dream Vendor"

• Continuous Integration
• Public Bug Tracker (even better, their Google Bug Tracker)
• Use Monticello2
• Provide a full stack implementation (One click image)
• Support multi-cpu
• I18N
• Provide a better GUI

Also - if you're here, they will be doing a Seaside Sprint Friday afternoon and into the weekend. They are addressing the Core, Library Developers, Porters, and Vendors. The main goal is to move 2.9 ahead. It's not clear where this will happen yet - check with Lukas.