Smalltalk Tidbits, Industry Rants

Vince Bourgon explains why getting things done in the "modern" languages is so painful - virtually nothing has been learned from the the past - heck, MS has even forgotten what made Basic productive...

No interactive interpreter

I think this was one of the biggest annoyances of all. When I learned languages like Python, like Common Lisp, like Smalltalk, it was always possible to easily and interactively test things. The fact that to test simple things in C# I had to build a whole program, write what I wanted to test, have some output functions to see the results, compile and finally run the program. This took time, and when I had a bug, I had to go back to my editor, find the faulty line, fix it, save and try to compile again. This was much slower than using an interactive interpreter. I had never used sockets in C# and had to make a small program to see how they worked and all. Again, an interpreter would've made things easier and faster. If it wasn't for the very complete MSDN documentation, C# would be a much, much tougher beast.

Gosh knows how far I ever would have gotten with BottomFeeder without the power of Smalltalk. Clearly you can do such projects in C# or Java; there are plenty of such readers out there. But it's harder to get things done. When it's hard to get feedback, it's hard to be productive. And then look at this example:

Simple stuff is made complex

My program contains a Hashtable with the keys being school numbers their name (001 - School Foobar) and values being their IP address. When I ran the program for the first time, I realized something that I hadn't thought of: Hastables are unordered. I wanted the school to go one by one, in alphabetical order. I had this line in the program foreach (string key in ht.Keys)

So I said to myself that the simplest thing would be to change the line to:

  foreach (string key in ht.Keys.Sort())

But this resulted in a compiler error. The hashtable Keys properties returns an ICollecton object which cannot be sorted. So I thought, I just need to take the ICollection object and cast it to an ArrayList:

  ArrayList myKeys = (ArrayList)ht.Keys;
  myKeys = myKeys.Sort();
  foreach (string key in myKeys)

But this raised a runtime exception. After some googling around, I found a solution on this page. Basically, I would need to create my own class called IterSort() to sort the keys. Who else thinks this is way too hard? On the other hand, look how I could've done it in Smalltalk:

  
  d := Dictionary new.
  d add: 'Hello' -> 'World';
    add: 'Bonjour' -> 'Monde'.
  d keys class. "This returns the class of keys, which is a Set"

Now that I know it's a Set, I can just sort it by converting it to a sorted collection:

  d keys asSortedCollection.

The whole thing is just so much easier in Smalltalk than in C#.

He's got other good examples, but the two above illustrate something - yes, there are scads and scads of libraries available in Java and C# - this is something that is continually pointed out to me. On the other hand, if you have to constantly plow through crap like the above, I'm not sure the library size buys you as much as you think - especially when systems like VisualWorks already support a sizable proportion of the extant stuff you need. Take a look at his article, and let me know what you think.

Brad Abrams covers some of the TechEd sessions.

There's a Java/Server conference going on - I've been reading the coverage over on the Bile Blog. It would be nice to get an alternative POV :)

Wired News has a report on the WinHec conference (held in Seattle at the same time as StS, actually). I was kind of interested in some conference reporting - something like this or this from StS. However, all I've been able to find is stock media summaries. Were there no bloggers taking notes?

Via Lemonodor

<malaclyps> i'm going to Camp Smalltalk this year
<malaclyps> i believe as a UN Observer
<malaclyps> it's like Camp X-Ray but the interrogators try to get the prisoners to document their code

LOL

Pete Kruckenberg makes some good points while letting a rant go about Java - here's what I mean:

If you can't develop Java code that is 100% compatible with every version of every JVM, in an application that is compelling to be portable, don't bother. Compile it to a binary for the platform that I'm using, and make it look as good and work as good as any other application for that platform.

Ignore the reference to Java there, because it's a universal thing - end users want an application, not an installation problem. I've tried to get there with BottomFeeder - the only place I really miss is Mac OS 9 (I still need access to the hardware). From the few people who have tried downloading Bf for that platform, I know where Peter is coming from.

PR Opinions posits that the wider array of information available (for any and all products) is making the sales cycle longer and more complex:

In the past, I might have got a couple of brochures from some manufacturers, visited a couple of retail outlets and made a decision. Today that purchase process is far more complex.

I'll search for all the manufacturers. I'll go to all their sites and read their literature.  I'll visit the relevant magazines and read the reviews, visit mailing lists, consumer opinion sites. I'll still pop into the retail store and finally I'll make my "educated" opinion. Then, once I've parted with my cash and my post-purchase cognitive dissonance sets in, I'll re-visit my chosen vendor's website to be reassured that I made the right decision.

That is a longer and more demanding sales cycle.

Hadn't really given this much thought, but it sounds right. There's a positive to this as well - in the software space, the "row of books at Borders" problem has been ameliorated somewhat. As more and better information appears online, you can compensate better as a niche player. It takes work, of course, but it can be done. Read the whole thing.

Ted Leung points to some IBM blogs - Grady Booch and a number of other people are listed on the site. Ted is complaining about the RSS feeds being for the current month only. I'm not going to complain about that - the feeds for the Cincom blogs are a rolling snapshot in time. I'll have to trawl through the IBM site and see what looks interesting.

Nasa aims to find out - check out this experiment.

Joi Ito points to an NYT article (free registration required) on IRC - surprise - the Times is convinced that IRC is a huge den of iniquity:

Even as much of the Internet has come to resemble a pleasant, well-policed suburb, a little-known neighborhood known as Internet Relay Chat remains the Wild West. While copyright holders and law enforcement agencies take aim at their adversaries on Web sites and peer-to-peer file-sharing networks like Napster, I.R.C. remains the place where people with something to hide go to do business.

That's right gang - all we do on the Smalltalk IRC is trade illicit copies of movies and games. No technical conversations, no meeting with far flung friends, no ad-hoc support - not according to the Times. It gets worse:

"I.R.C. is where you are going to find your 'elite' level pirates,'' said John R. Wolfe, director for enforcement at the Business Software Alliance, a trade group that fights software piracy. "If they were only associating with each other and inbreeding, maybe we could coexist alongside them. But it doesn't work that way. What they're doing on I.R.C. has a way of permeating into mainstream piracy.''

Ahh, the fine folks at the BSA have been interviewed. These are the people who who help transform your business into a user hostile gang. And the NY Times is enabling that sort of mindset to spread with sludge like this:

When I.R.C. started in the 1980's, it was best known as a way for serious computer professionals worldwide to communicate in real time. It is still possible - though sometimes a bit difficult - to find mature technical discussions among the tens of thousands of I.R.C. chat rooms, known as channels, operating at any one time. There are also respectable I.R.C. systems and channels - some operated by universities or Internet service providers - for gamers seeking opponents or those who want to talk about sports or hobbies.

Still, I.R.C. perhaps most closely resembles the cantina scene in "Star Wars'': a louche hangout of digital smugglers, pirates, curiosity seekers and the people who love them (or hunt them). There seem to be I.R.C. channels dedicated to every sexual fetish, and I.R.C. users speculate that terrorists also use the networks to communicate in relative obscurity. Yet I.R.C. has its advocates, who point to its legitimate uses.

After the obligatory "some people on IRC are ok" comes the slam - and it's quite a slam, making sure to associate IRC users with groups that the mainstream Time reader is going to find unsavory. Here's the thing - IRC is no different from any other human activity. There are nice places and not so nice places. Just as there are clubs where you can go and hear music (and others where people engage in slightly less savory activities) - there are a wide variety of IRC channels. I suppose the Times has to play up the "ugly" as a way of pushing sales. People are people, online and offline...

Via CLS, news of an upcoming STUG meeting in NYC - if you missed Smalltalk Solutions, here's a chance to see one of the talks:

Please join us for our second presentation of the month on May 18th.

Speaker: David Buck
ElastoLab is a shrink-wrapped VisualWorks application that allows kids to design their own 2D scenes that incorporate physics elements like particles, springs, and gravity and lets them see their scenes animate in real-time. Originally written in C , it was later completely re-written in Smalltalk.

David will be talking about the development history and the design challenges in writing ElastoLab. The talk will explain:

• how to interface to the Windows sound facilities from Smalltalk
• how to make graphical applications run quickly
• how to package a Smalltalk application for release
• developing help facilities and guided tours
• using the web toolkit to develop a message board on the Internet for ElastoLab.

A CD-ROM of ElastoLab will be available to all attendees.

Date	May 18, 2004
Location	Suite LLC offices
Address	440 9th Avenue, 8th Floor
Time	6:30pm to 7:00pm -- Open house
Time	7:00to 8:30 pm -- ElastoLab

Directions:
Take E or C train to 34th (Penn Station) walk to corner of 34th and 8th. Walk up one block to 9th.

RSVP is requested. Please send mail to: charles@ocit.com with subject line of: NYC Smalltalk May 18th, 2004.

Via CLS, news of the next STUG meeting in NYC - if you missed Smalltalk Solutions, here's a chance to see one of the talks:

Please join us for our next meeting to be held May ,Tuesday 11th.

The OpenSkills Skillsbase Project
experience report
Bruce Badger: OpenSkills

Abstract: The OpenSkills SkillsBase is implemented using the Swazoo HTTP server running in GemStone, all hiding behind a Squid reverse proxy.

Bio: Bruce is an enthusiastic technologist and the Founder and President of OpenSkills, a global non-profit association of professionals who provide a wide range of open source related services. His strong technical leadership skills have contributed to his success on a huge diversity of IT projects, over a period of more than 20 years. He has built and deployed many Smalltalk systems and libraries over the past 10 years.

Date	May 11, 2004
Location	Suite LLC offices
Address	440 9th Avenue, 8th Floor
Time	6:30pm to 7:00pm -- Open house
Time	7:00to 8:30 pm -- OpenSkills Skillsbase Project

Directions:
Take E or C train to 34th (Penn Station) walk to corner of 34th and 8th. Walk up one block to 9th.

RSVP is requested. Please send mail to: charles@ocit.com with subject line of: NYC Smalltalk May 11th, 2004.

Yahoo points to Cincom's congratulatory message to Alan Kay.

It's been a great show - My talk went well this morning, and I received some very nice feedback - thanks to all for the great questions! It's been good to finally meet the withStyle team face to face - I look forward to seeing the lot of you in Australia, even if I have some trepidation about the vegemite you provided :) It was a great show, and I hope we have as great a time next year.

Brian Rice talks about Slate. Generally works in language research - very inspired by Self - working with Lee Salzman (not here) - designing Slate with him. Looking for flexibility and minimalism. Want to do what Squeak does, but better. Slate is free, under the MIT license. Want to use a lot of the good ideas in Smalltalk, and bring them together. Admits that the number of unique new ideas in Slate is small. Implemented first cut using Lisp. Why a new Smalltalk? Self and Strongtalk promised change, but we ended up with Java instead. The existing ST vendors have customer bases to deal with. Squeak is free and malleable, but has too many small issues - new designs can't tackle all of them. Really wanted to push together the right set of ideas in one place.

Influenced by Self and Strongtalk. Also by CLOS and Dylan. Wanted to combine best ideas from these disparate systems in one place. Slate development started in 2002. Self was not practical - big demo. Squeak was moving in too many directions, in their opinion. Slate the language is based on objects with slots, prototype based language. methods are blocks that close over their arguments, and have a syntax signature that activates them. Smalltalk is single dispatch - Slate is multi-dispatch. Slate specifically allows for object-specific behavior and state, and multi-argument dispatch. They call this combo "PMD".

All arguments are receivers and they play different roles. Objects do not relate to methods in the same way they do to their slots. methods are cooperatively held between many objects. No self/super keywords - not reserved. lookup is accomplished through messages to the context

Method lookup is performed in cooperation with the arguments - dictionary is searched depth first, left to right, methods ordered by their "distance" from the arguments. The distance is "deterministic" and the "closest" method applies. Optimization needed to be done early as a result.

Slate started with Self's inheritance model, using special slots to store delegates. Shared "traits" contain behavior, not state. This was found to be too dynamic. a pattern - does not distinguish enough. Now looking at new models - Looking more closely at what Self did with descriptors. Looking at Squeak traits for ideas.

Wanted to keep the syntax as close to Smalltalk as they could. So what's it look like?

collections 
	addPrototype: #NoDuplicatesCollection
	derivedFrom: ExtensibleCollection.

nd@(NoDuplicatesCollection traits) add: obj
[
	nd include: obj
].

So it looks like Smalltalk, but oriented in a prototype based direction. Macro-methods - syntax parse trees are an object medium for communication. can annotate these with type info or declarations, or describe a pattern that the compiler van recognize and optimize on. There are tools being built for this.

Summary - this is very early development work - the VM has only just been done - it's a work in progress. Plan is to go VM-less and bootstrap.

Smalltalk evolution panel at StS 2004:

Members: Lars Bak, Martin McClure, Vassili Bykov, neil Konz

Vassili: Evolution happens. Works on tools, not the "language part" of the system. Still, gets to be in that area quite frequently with what he does. Pretty much, given the way Smalltalk works, we all end up playing in this area.

Neil: Agree that evolution happens. Especially in Squeak, it moves in a lot of areas at the same time. A surprising number of Squeakers are playing the language design/evolution area all the time. Evolution in how it's being used. While Alan Kay had the initial vision, he's not pushing from that end. He's funding/pushing his own projects - he looks at is as infrastructure. Some are evolving to make it smaller (Squat), make it a Web Services system, Seaside, graphical experiments (Croquet)... No one is selling it - has pros and cons. Good: No one to kill it, can only die through lack of interest. Con: It's a "spare time" thing, people will only work on things of interest to them. Smalltalk has a bright future for server side work and scripting - other scripting things aren't as good

Martin: Smalltalk needs to get better - contradictions:

• Size
• Smalltalk should get larger (Gemstone - bigger repositories, etc)
• Smalltalk should get smaller (embedded systems - like Lars)
• More Innovation, but also more interoperability between dialects. Should be more discussion between implementors on what is happening and what should happen. Too many times we've had slightly incompatible similar ideas.
• More free Smalltalks - commercial Smalltalks need the ideas

Lars: I'm not a language designer - what will get it more accepted? Better support for Scripting - need to be able to use Smalltalk from "standard" file based tools. The other scripting languages (no names :) ) are pretty much all bad. Focus on what Smalltalk is good at - need to quantify it better. Talk about features, not "religion". Should have a Scripting Smalltalk

Q: Eliot "hijacks" session. Smalltalk community is simply that "we're better" - no uptake, turns people off. Need to explain what actual problem we are trying to solve. Want to sell aspirin, not vitamins.... Draws us a picture of where Smalltalk ought to grow. Off into a business model thing....

Lars: Find a niche where you are better than the competition and try to grow there. Don't fight the same battles - find new markets.

Alan Knight: Push simplicity - point out how easy it is to get started. Point out how quickly you can get into the system and start accomplishing things (closer than where step 1 is "create the XML manifest file"

Bob Nemec: We are techies, not marketers. Have the STIC step up more - get the word out.

Neil: Have to reach the decision makers - not just the tech guys.

Me: Get involved - Get a blog, get the message out there.

Sam Shuster: Get better pages to show up for Smalltalk searches on Google

Vassili: How to carry the message - make sure that the message is positive, not snarky or put down -

Dennis Smith: Marketing - there is stuff we can do. Starting with VWNC is not as simple as it could be (ed. - the New Class dialog helps). Generally, the ramp into the product is harder than it needs to be. Say I wanted to introduce Smalltalk to high schools - what can we point to as help?

Martin McClure: Squeakland.org and EToys. This is solved somewhat in Squeak.

Neil: Yes, EToys and the toys associated with it really does work for getting people into scripting - can and is being used to draw people into Croquet. "People don't buy languages - they buy solutions to problems". Got into ST by looking for something like ControlWorks

Bruce Badger: talk to Linux groups, introduce things like Squeak and VWNC to people, show them what you can accomplish with these tools. Show the open source one, show the commercial one - crowd was very pleased

Rich Demers: Wanted a panel on what should be done to evolve Smalltalk, not a marketing discussion. Lots of things have stayed the same since Smalltalk-80 - should we look at new things for Smalltalk? Look to other languages for ideas? Need some forum for talking about these sorts of things - some organizational thing through the STIC?

Alan Knight: STIC is not a faceless thing - it's a known group of people who are quite busy, and spend most of their time organizing this show. After this show we may actually have some money and be able to do some things - but we need help. "Ask not what STIC can do for you".

Martin McClure: Evolving is done in order to survive better. Need to get the word out in order to be able to evolve.

Bob Nemec: There is a large open source community around other things (Linux). Perhaps we should come up with a "common Smalltalk" effort.

Alan Knight: Not true that all the work is in Squeak - Ralph Johnson's Camp Smalltalk effort has worked very well. Lots of open source work in VW as well.

Sam Shuster: Dialect portability - used to do SUnit ports across ST dialects. For a long time was concerned - at this point: "Who cares?" Bob: Risk management

Martin Kobetic: Too short a time to get things done, nothing gets done between the sessions. "What is Smalltalk?" Squeak? VW? There are efforts (like GLORP), but it's fragmented.

Hunter: used to do Smalltalk back in the 80's - now doing financial services, came here because "it's time to do Smalltalk" - web services make it easier, "no one cares if the server is Smalltalk". Offering a clean object platform that can deal with standards based communications are possible. Only obstacle - getting the examples to work are harder than they need to be.

Lars Bak's keynote address on embedded work in Smalltalk. Lars was involved with Strongtalk - Animorphic, was also involved with HotSpot at Sun - now this

How to make embedded systems "servicable" - i.e., how do you update the thing in the field w/o having to recall it? Example - visiting a VC, met an exec with a big car, digital display - "BSOD" on the screen, had to "reboot" the car - the vendor's answer was basically "yeah, so?". With phone users, you can't get updates as you do with desktop clients - phone users will just switch phones. Need a better way to keep these users.

Past VM experience:

• 1986 Beta - 1990 Self
• 1996 Java HotSpot - 1993 StrongTalk
• 2000 CLDC HotSpot - 2002 Resilient

Wanted to sell StringTalk to Wall Street - but the Wall street folks were thinking "Java" thoughts. Went on to Java HotSpot. Now working on Resilient. So the agenda:

• Resilient in embedded systems
• A variant of the ST language - some additional syntax, will explain
• Implementing OS services
• Product licensing

This is a technology preview at the moment. VC backed company. getting second round of funding, so they are moving forward. Today, most of the embedded systems are pathetic - they use C linked to an RTOS kernel. Very slow to build and debug. In this space, short turn-around times are critical - with some electronic toys, times are measured in weeks. Updates are either not possible or monolithic firmware updates (reboot). Typically using unsfae languages, no servicability, very static model. Support is "reboot it and try again". Customers don't like that idea.

Predictions for this space?

• Software quantity doubling annually
• By 2007 it will be impossible to buy a non wireless device
• Device R&D is dominated by software development. True even in "old line" industries like auto

What does inductry want?

• Increased reliability
• Low cost (resource constraints)
• recalling a device (like a phone) can run to $50 per device)
• Dynamic updates in the field
• Real time capabilities
• Rapid development cycles

Is embedded Java the answer? - No

• Does not support incremental execution
• VM spec is very complicated
• Bytecodes not designed for speed and compactness
• Configurations for embedded systems are too big
• CLDC and CDC
• Configurations are growing...
• Resilient is targeting down to 128k size chipsets

What can we do better?

• Dynamic language
• Increased productivity
• Connect dev env to the running system
• On the fly updates

Example - Bang and Olufsen tested Resilient to service and control a digital speaker. Able to do field updates w/o recall to the shop. Customers don't like having to do manual turn-around. Transparent updates possible (as is done with ReplayTV and TiVO devices) - have it updated w/o user having to deal with it.

• Platform for crearing secure, OO real-time software
• Minimal memory
• increased productivity
• Enables correction in the field - with deployed software

Examples - take a snapshot of field system and send back to engineering for analysis. use SMS for pushing updates. Two pieces:

• Embedded Platform
• OO OS - 32K
• Pure OO System
• Platform independent mobile code
• Libs for device drivers, networking
• Unified resource mgmt - everything is in one heap.
• IDE
• Connectes to running system
• Supports true incremental execution
• Full servicability and visibility - can change device drivers as it runs

This stuff can be deployed on small hardware (With Bang and Olufson, they had 256K - so they tossed in a web server so that they could look at the results). Cell phones are another platform - especially the ones not running an OS - can add in this system pretty easily. You can use this on a host OS (desktop) for development purposes. The development environment provides the reflective behavior, reflective ifc in the device - allowing for changes to all subsystems in the device. They have customized Eclipse for Resilient. They have also done this for Smalltalk/X, but did not like the environment. Programming support for debugging, profiling, introspection in the plugin... They built the Eclipse support using the Eclipse plugin support.

The VM is portable and simple. 32 bit VM, compact object model, scalable object heap. new bytecode set for Smalltalk. 20 bytecodes with uniform format. Optimized interpreter, inline caching.

• Unified Automatic resource management

• real time GC
• policy based, user definable
• guaranteed allocation/scheduling behavior per thread/application

Smalltalk with a few twists - trying to make a simple system

• Introduced full syntax for classes
• Allows for File based storage
• Atomic test and store statement
• Namespaces
• Typed LIFO blocks
• Removed
• Pool variables (not useful)
• Class instance variables

Shows us the file format for code - looks pretty simple, only a few nits from the crowd on assignment of stuff. method def:

key	=	(^key)

Critique - use something other than "=" for defining a method. Now, blocks in this system are not full objects, so when using them you have to declare them. Minor restriction. The main thing is, it looks like Smalltalk. The changes are all related to issues surrounding actual issues in this field:

• Device constraints (memory, etc)
• Developer expectations in this field (file storage, using tools like CVS)

Class libraries - minmal set of libraries provided. No reflective behavior - only the programming environment can create a class. #perform: is not supported - makes it easier to determine what needs to be downloaded to the device. Scheduler and device drivers are supported, as are standard network libs (TCP/IP, SLIP, NIC, Firmware). Small collection hierarchy. Shape changes are supported. Example:

• Two kinds of integers
• SmallInteger (20 bits)
• LargeInteger (32 bits)
• Writing device drivers on a 32 bit computer requires 32 bit arithmetic.

Namespaces - Able to modularize code. Classes can contain other classes, which is how namespaces are implemented here. Accessing:

Network::Service::Echo install

Performance - issues

• Allocation of block contexts
• inlining of control structures
• flattening of code (Collections)
• Interpretation overhead
• Slow method invocation (only 32K available here)
• results in breaking down code abstractions
• or apply advanced inlining compiler

Block example - Typed LIFO blocks. Stack allocated contexts require no escape guarantee. LIFO block ikmplementation speedd up block code.

collect: [collect] do: [block] = (self do: [:e | block value: (collect value: e) ].

Sharing methods - 10% of methods can be eliminated by doing this (sharing byte codes). "Super byte codes" - computed based on static bytecode pair histograms. With space for 255 byte codes, and only 20 in the system, can create "app level" byte codes on the fly doing runtime analysis.

The Scheduler is written in Smalltalk - so that's field servicable as well. Very cool. The device driver API is simple, mimics the raw hardware. VM provides an abstraction layer. The resilient VM is 2X faster than the JVM for these devices! Supports:

• Bunch of devices - see the site (below)
• IA32/Linux
• StrongARM/Embedded Linux
• Windows
• Symbian OS
• Mac OSX

tech preview available at http://www.oovm.com. Free for NC, pay for commercial. OOVM is actively looking for initial projects, and will make it attractive for prospects.

And a demo - plugging in his phone to his PC, and connecting to it. Synching dev env classes with the device. Developer gets notified of what's there and what's not. And he's executing code on the device. There is exception handling, very simple, but follows the Smalltalk model, using a Java-like API (throw, try, catch). And there's a Wiki here

Mark Roberts and Rich Demers talk about SmalltalkDoc. Mark started with ST back in the late 70's at PARC. Rich started with VAST back in the 80's. What is SmalltalDoc?

• Standards and Facilities to provide reference documentation for Smalltalk
• Authoring tool in the IDE
• Web Application for browsing

The goal is to separate the documentation from the implementation of the system - allow people to learn w/o reading all the code. The documentation can be gathered from a Store repository by the application. Who is the intended audience?

• primarily new developers
• reach out via the internet
• not a substitute for PDF - an addition to online help

Why Smalltalk Doc?

• Reduce the time/effort to learn ST - get them up to speed quickly
• Provide a simple overview of the environment and lower the learning curve to a learning bump
• Improve the "out of the box" experience for developers new to ST. Motivations:

• Need reference doc - we used to have the "Cookbook" in 2.5, but it was huge, and never updated. The ObjectReference was a stab at doing this
• Emphasis on use of the class library
• "Learnability" vs. "Simplicity"
• Learning the class and pkg library
• Need to clarify the functionality of the system
• One of the big issues is the API - what is it? In many cases, our libraries have no API in the sense that developers in other languages define the term. It's a manual "eyeball" process of inferring the API...
• Making the system more approachable is a key goal

The general issue - we have a gap in knowledge - we doc the system, but do not have a "Users Guide" for new people. Using this:

• Authoring content in the IDE
• Generating content for the web
• Browsing content for the web

Now Mark is going to demo the system. The system is built on a content mgmt system built atop an OODBMS. Presented via a VW web toolkit application. What he's got is a prototype that can produce a doc view of the class library - from the package and class view. Now on to Rich. Hmm. UML diagrams of the domain. I know these are useful, but w/o a camera, I can't convey what I'm looking at here....

They have a browser-like tool for displaying and editing content. Basically, the same information that was available on the web side is available in the browser view. The bottom view is an HTML Pane (Twoflower now - WithStyle eventually? Content entry is text. Interesting flare up of conversation on the concept of entering content - current prototype requires HTML tags - why not Wiki markup? Too much work - they want a WYSIWYG kind of tool in the end. The content will be stored as XML.

Q: How does this information get entered in the first place?
A:: Information gathered automatically (garnered from the Smalltalk system), converted into an XML form, and then translated for display. The idea is to keep all this info with the code so that it gets versioned off in Store.

Q: Does this work at all with the Web Services work?
A:: Huh?

Q: What about using something like the JavaDoc approach?
A: The desire is to integrate this with the system. Should be possible to create a tool to "peel" the doc off from the system. The domain model is tied into the code, so it stays with it. The idea is to keep it that way.

Q: Will there be an interface for end users to "mark up" the documentation?
A: The web side? Sure, that could be added via permissions. The tools themselves will be available for end customer use

Day two of StS 2004 is done - all my reports are up, and Michael has a bunch up as well. We're off to the Space Needle - I have to talk at 8:30 tomorrow morning - come learn about BottomFeeder.

Len Lutomski, Martin Kobetic, and Sean Glazier are going to discuss what's been happening and what's in the pipeline in the general area of distribution tools in VW

What's new in VW and OST?
Agenda:

• VW-OS interop
• ASN.1
• Opentalk enhancements
• Opentalk IIOP
• WebServices Tool
• SSL

VW-OST interop - OST has native widgets and a nice story on business interaction with databases. VW has a lot better server support and scalability (and more platforms). Now we have a simple demo of VW - OST - two images, VW, OST. Some simple workspace code in both places. The demo - push a bunch of objects from OST to VW, and print them to the Transcript - and it works! It's not done yet - no demo of other direction yet due to some issues. It's almost done, and will be ready to use in the next release. It's at beta (in OST) now. Have not ported multicast stuff, had to make some changes due to socket, threading, differences. The main warning:

OST users should never open an Inspector on a RemoteObject or any subclass of SelfInitializingObject. Has to do with remote references. In the beta, there are issues with remote exceptions across the boundary - those will be fixed before release.

There are app level issues - class differences, divergence in core classes (Character, Set, Point, Time...). Differences in Blocks, Namespaces - but the basics work!

ASN.1
New marshalling framework for dealing with ASN.1 - fairly complex structures to deal with. The marshaller is pretty fast - a lot of optimization has happened here. So - why did we bother with ASN.1? It's used all over - LDAP, SNMP for starters. Also, VW 7.2 actually had 3 separate variants on this - we are unifying the framework. There are many different encoding styles - BER, DER, PER...) - doing this exercised the marshalling framework and allowed us to "shake it out" in a productive, useful way. Also gave us a way to experiment with abstract type systems (useful in FFI work) in Smalltalk.

Opentalk Enhancements
In version 7.1, enhanced the protocol - released an update.

• Increased the number of tagged classes with optimized marshaling
• Added tags for user employment
• Added two new pass modes
• pass by name
• pass by OID
• refined pass mode control

Improved Connection Handling
In client/server - evil to drop a client request. In the web world? If we get overloaded, it's ok to drop them. What we did is to make the web server load handling more robust. Added load balancing, pushed the Wave/WTK server to Opentalk. Added an Opentalk console - makes it easier to configure and manage orbs.

Remote Debugger
Attach and debug - i.e., attach a debugger to a remote system. Managed through a simple API - allows you to set up a way to debug a headless image, remote or otherwise. Allows you to define a "monitor" image which exceptions will end up getting forwarded to.

AT Profiler
Replaced the profiler (monlithic) with a modular piece of code that supports multi-process profiling. This is the first step towards making this stuff fully supported.

Opentalk IIOP
The re-implementation of DST as part of Opentalk. This will make our CORBA story up to date and allow for support of things like RMI over IIOP - i.e., better Java interop. So Martin has started a Java ORB and name service, as well as a Smalltalk broker. Reusing a lot of the old DST infrastructure. Replacing the transport layer.

Web Services Wizard
You want to make some existing VW piece a web service, or hook to a remote web service. He's showing the actual wizard - I suppose I should try building a trivial service with this and blog about it at some point. Generates the server (SOAP) class for you. You can also have it generate an Opentalk client for you, and have it generate a simple test script. And it can generate a WSDL file as a file, as a class method, or as a document posted to a URL. And you can do it in reverse from a WSDL file as well.

Security Enhancements
Cleaned up the public APIS, starting in VW 7.1 supported things like DSA, RSA, Diffie-Hellman. in 7.2 the hashing APIS were cleaned up, allowed the computation of a running hash. And it's all documented in the SecurityGuide.pdf (in the docs). In 7.3 we plan to get X.509 and the new ASN.1 frameworks done. Allow generated keys to be imported/exported in standard ways.

SSL and Https support
How about an HTTPS server? That's supported as of 7.3. Lots of small improvements here "under the covers". A short customer story:

• Financial house posts trades to NASDAQ using HTTPS client and SSL framework.
• Saves $5000/month over an MQS link to NASDAQ
• No manual entry - HTML pages are automatically read, filled in and posted. Report and retrieval is automated as well
• Other companies are still using MQS a and struggling to manually enter data within the 45 minute NASDAQ requirement
• Implemented in less than a month and running for over a year
• Handles 30 million callbacks per day on average from other systems.

VisualWave updates
Brokers moved over to Opentalk - unifies the server framework, easier to maintain. Completing the migration of infrastructure over to Opentalk.

What's Next?

• Consolidation - trying to do too much
• Will do a few new projects as required
• There are things the team wants to do anyway :)

Want to distribute all the tools - browser, debugger, profiler, inspectors - everything. Long range plan - won't happen until a lot of other things gets done first. More work on the load balancers - state replication and failover. Remote configuration - would help in Automated testing. In that vein, make SUnit remotable. Coming soon - VW-MQS bridge. It's being done by Heeg as a service job, will come in as preview soon, supported later.

Q: MQS should be accelerated
A: It'll be in preview for 7.3, supported afterwards. You'll have access
Q: What about using SRP for passing by value?
A: We would have to look, can't make any promises. We do need to look at that area though, and it's something we plan to look at

A .NET developer asks:

All these languages (Smalltalk, Python, etc) are pretty far from being strongly-typed imperative languages, so it seems that it is indeed possible to use more dynamic languages on the .Net platform. Indeed, Jim Hugunin, the author of IronPython (and Jython, the Python-on-JVM implementation) notes that while his initial intention was to write an article titled "Why .NET is a terrible platform for dynamic languages", he ended up with the conclusion that the CLR is indeed a good platform for dynamic languages. My question is: Is anyone using these languages on the .Net platform in real projects? I'd be very interested to hear any success stories.

Any answers?

Vassili Bykov discusses the VW tools. Vassili: "My hair isn't blond, it's gray. It was black when I started working on VW Tools". Vassili points to the badges, where the names are like this:

James

Robertson
Cincom

Given the font usage, it looks like I work for "Robertson Cincom". Point is, presentation matters. So if the presentation is confusing, the user won't be able to figure out how to use it.

Trippy
A demo - a couple of inspectors. Showing multiple select, and that you can do "accept" of values across all selections. Yes, there's an undo. You can drag/drop between inspectors, and within an inspector (re-ordering an array, for instance). The evaluation pane adds a workspace in the tool. There's also navigation (dive down, etc). Here's a screen shot:

Next - pragmas
Started to appear for dynamic menu additions in VW3. Why was this required? Well, say we add in a tool (3rd party) that needs to add a menu item. Now posit a second tool that wants to add another new menu item? The last one to modify the menu wins. Pragmas solve this by allowing the menu to be defined in chunks. More uses of pragmas:

methodWithPragmas
	

	^3   4.

Look at the byte code: No byte code for the pragma? Look in attributes under attributes - annotated Method. Here's a screenshot:

Add a class method like this to get rid of the warning:

pragmaDeclaration
	

	^#(example:difficulty:)

You can write "script" to collect up methods with pragmas and figure out where they are. Then you can script this in the inspector - as Vassili just said: "Try that in Eclipse". So back to menus - the system just collects up pragmas of a given sort (i.e., referring to a selector) and builds the menu. It turns out that Vassili has been using pragmas to extend various tools - like the new "dock" at the bottom of the VisualLauncher - see class VisualLauncherToolDock.

What about the matcher in the Store tools and the class finder tools? Have a look at class CompletionDriver. It's easy enough to "plugin" to a UI:

postBuildWith: bldr
	completionDriver := CompletionDriver new
		widget: (self widgetAt: #inputField);
		choicesHolder: (self computeCompletions).

Then you have to set up the #computeCompletions method - basically a matter of telling it what you are matching against and how.  

Tool Modules

Things like the IncrementalSearchDialog are built up from component modules.  The main one is IncrementalSearchModule (a class in VW).  The basic comment: "IncrementalSearchModule is a combination of an entry module and a list module. As the user types in an entry field, the module searches for objects matching the input typed by the user and displays the result in the list module.  ".  As it turns out, you can use this module in applications - it's pluggable.  There are a number of utility methods (like #forClassSelector) that make some uses easy, and point out how to build others.  The only other thing to do is to create a method for noticing changes in the input field, which in turn queries the module.  

Interesting - he's showing a pragma that lists a set of relays - more or less a smart delegation target list.  You can use this instead of a hairy #doesNotUnderstand: implementation.  

Ahh, the Settings Framework.  Made my life easier in [BottomFeeder>http://www.cincomsmalltalk.com/BottomFeeder].  Adding your own settings is pretty easy, and customizing the way it does storage of settings is very easy - it defaults to an XML file, and I have Bf dropping an ini file instead.  Cool - if you blow settings code, you get a "Debug" button right in the settings tool.  

Georg talks about Smalltalk on mobile devices. October - Cincom's German sales guy asks about Smalltalk on the pocket PC. Within a few months he was demonstrating VW on Windows CE 4. Will be fully supported in the 7.2.1 release (later this spring). What do you need?

• Win CE4.x (alias .NET)
• Windows Mobile for Pocket PC 2003
• Any variant of CE 4

Examples

Siemens Simpad PC, SkeyePad, Tatung Webpad, iPaq, bunch of others. Where did this idea come from? The DynaBook that Kay (et. al.) dreamed of at PARC "back in the day". Is this the Dynabook? Adele Goldberg Feb 2003: "This does indeed look like the original conception". There's more to the quote, whee she says that the challenge remains to make programming more like modeling, but it's too much for this non-touch typist to copy down...

What about the actual market? There was an interview with a Gartner analyst (Bill Clark):

• Pace is critical- mean lifetime of a mobile device is 18 months!
• ROI must be in 18 months
• Portability is important
• J2ME differs a lot from J2EE (as .NET compact differs from .NET)

Then there was Mark Driver, the Gartner analyst who stated that: "It does not matter what features Cincom Smalltalk has, Smalltalk market will not grow".
Tom Nies (Cincom CEO, 2003) - pointed out that there were proposals to close the US PTO in 1845, as "everything" had been invented

In Germany, mobile device manufacturers have become very interested in Cincom Smalltalk on mobile devices. Heeg produced a demo for this manufacturer (Hoeft and Wessel) in 25 hours for stock-taking, impressed them a lot. Asked for a demo and slide presentation immediately. He got a facility management application - and they released a press release to the mobile market talking about this. The upshot? Smalltalk is ideal here:

• Pace - productivity
• Portability - Windows/Linux/CE
• Technology does not matter as the devices are outdated in 18 months

Target Market

• Professional users of mobility
• Professional mobile software producers
• This space wants turnkey solutions, from solution providers

The competition?

• J2ME/PJ - incompatible with J2EE
• C/C - every device is different
• .NET Compact
• Considered immature
• Windows CE only
• Big Suites (IBM/Sybase/Oracle) of turnkey applications

What about Cincom Smalltalk Mobile?

• You need VW 7.2 VM for Windows CE (XScale/x86/StrongARM)
• CE parcel (part of the distro) - get the latest updates from the Heeg website
• Load CE parcel, deploy the application as appropriate - it should "just work"

Likely, you'll need to adapt the UI to work with a pen interface and the smaller screen turf. The bottom line though - develop on any supported VW platform, deploy to CE. No changes at the code level required....

How fast are these devices? Early Pentium range.

George Bosworth's keynote on the Microsoft CLR, and his personal comparisons of it to the Smalltalk/V VM. George was one of the founders of Digitalk

Why a personal perspective on this? George is one of dozens of architects on the CLR. Why compare specifically to Smalltalk/V? because it's what George knows best from the Smalltalk world. The CLR has been built by a lot of people coming from a diverse set of backgrounds - COM, VB/VC, J++, MTS, Smalltalk, Scheme, Lisp, etc.

I am and always will be a Smalltalk fanatic

Nomenclature - the CLR has lots of code names, and terms are and have been used over. George admits that he's not good at nomenclature anyway. "There are official names for things that he's supposed to know" :)

The CLR is a acommercial platform for languages and tools. A platform for languages and tools is trying to enable divergence and differentiation over time. A language toolset (like Smalltalk/V) is leveraging conformity and uniformity. So there's a different perspective. Smalltalk/V

• GC, IL Based
• Debugging, execution svcs
• SLL's
• FFI
• Smalltalk libs and components
• Basic language libs, change control, UI builder, source control

CLR?

• CLR Execution engine
• GC, IL, JIT
• Debugging, execution svc, remoting (etc)
• Externalized PE files (DLL, Exe) contain pieces
• BCL base class libs
• CLS language interop rules - this is the layer that defines how different languages will interoperate and play together here
• Pile of specs - important to a platform
• Codified standards

• What's not part of the CLR? Lots of tools and services and libs from others (both in and out of MS).

Where are the tools and libs? Available from MS and others (insert marketing information here :) ) Unlike Smalltalk vendors, MS not trying to provide everything - providing a platform to build on, not an end all. The CLI runs in something and things run on it. As a technology, the CLR is similar to a Smalltalk VM. It's in the details that diffs emerge.

The CLR is not itself a product though - things built on it are products. As opposed to Smalltalk, which is sold itself.

Now a walk through the CLR (Common Language Runtime). There are actually many CLR implementations at MS:

• Desktop/Server (CLR)
• VS.NET
• WS2003
• Whidbey
• Longhorn
• Rotor - close to desktop version, under shared source license
• Compact Framework
• Phones, PDAs, etc
• SPOT watch - see Scoble's blog

This talk is mostly about the desktop/server implementation.... The runtime control flow looks a lot like any other VM (In particular, like the JVM with the security model). So code (VB, VC, etc) compiled to IL, which the JIT then turns into native code which executes. There is an FFI. There's an interesting "pre-JIT" piece as well which he'll get to in a bit.

• "Econo Jit" - used in Rotor (slow)
• generates unoptimized native code
• Code can be discarded and regenerated
• "Standard JIT"
• Generates optimized native code
• Pre-JIT generation
• Done at install time
• Reduces start up time
• Native code has version checks and reverts to runtime JIT if they fail
• Assemblies - akin to parcels, SLL's, Squeak Segments
• One or more files, independent of packaging
• Self describing via metadata (manifest) - everything but the executable bits
• Versioning
• Captured by compiler
• policy per-application as well as per machine
• Security boundary
• Assemblies are granted permissions
• methods can demand proof that a permission has been granted to entire call chain
• Mediate type import and export
• Types named relative to assembly

What happens at compile time?

• Compiler reads imported metadata and builds internal symbol table
• Compiler resolves method overloading using languae specific type matching rules
• Compiler adds any required coercions or casts
• Compiler selects and records a precide member ref
• Compiler provides object layout requirements through its choice of
• Layout technique
• Non-static fields
• Virtual methods, with "new slot" vs. "use existing slot"
• Compiler emits metadata by nerging incoming metadata with metadata that's been generated
• Compiler emits IL with metadata tokens

What happens at class load time?

• A type ref occurs and is resolved to an existing type or an assembly ref
• Assembly is loaded
• If no managed native code available, IL module is loaded and first validity checks run
• Class is then validated and the CLR creates in memory data structs
• On first run, JIT is used (and verified if needed)

Jit - a whole lot of stuff you expect (inheritance checks, etc) happen - plus security checks. Finally, the code runs. Permissions can apply here - the security model can block this. This is a richer model than Java, because it sounds like it can be much more finely tuned. Ok, a picture of the "standard" model for compiled apps - code to exe file to directory to run. How about the managed world? source to IL assembly. To deploy, you can use tools that verify the assembly. PEVerify will do checks on the assembly. Then deploy to the GAC (the new registry!). To run, the assembly is loaded and the policy manager checks permissions (based on security model, if any). One interesting fallout - Assemblies (and the CLR) have been written to be hosted inside other applications. Different from most Smalltalk systems.

What's the Pre-JIT? an MSIL to native compiler. precompile, pre-load, pre-layout. Validated at execution time. May factor in the processor type, other assemblies, etc. If it ends up invalid, the normal path is used. The goal is to speed startup time - due to a smaller start up working set. Usually used as part of assembly installation. This tool ships as part of VS.NET - ngen. The theory is that a lot of steps get jumped if the pre-compiled assembly is valid at runtime.

Deployment Models

• Shipping and Installation
• Compile IL in build lab
• Ship IL
• PreJIT during installation
• Possible JIT during execution
• patching and servicing
• Deliver new IL image - could be huge though
• Repair native images (all depending on assemblies)

Application Domains - where assemblies are loaded and executed. Subprocess level of isolation. Defines own types and manages own memory - controlled by hosting policies. Objects in the domain are isolated from other domains, and will talk to them via remoting (proxy operations). This allows you to run disparate versions of libraries and have them all work. Hosting is about policies:

• Security
• Threading
• Threads vs. fiber scheduling
• Robustness
• Exception propagation
• Hosts load, initialize, and set policy for the CLR

An example - SQL Server won't allow a loaded application to use threads. So if yours does that, it won't load you. I see the point, but I have an issue here - same one I have with the final/sealed quandary. To my mind, it all assumes that the developer shouldn't have control...

What about memory issues? Again, this ends up being a policy setting thing. Ok - on to ST comparsion - he's calling it a toolset vs. platform view (I'd argue that Smalltalk, particularly VW, is a platform - but I get his point). The platform (CLR in this case) is concerned with guarantees that people can depend on. Language models (here he means Smalltalk) is different and concerns itself with conventions.

Specs matter more to a platform - changes affect too many people, so they are difficult to fix. Interestingly enough, Joshua Bloch of Sun said the same thing at ot2004.

Opportunity for questions:

Q: Rotor vs. CLR
A: Lousy code generator. Not as optimized. Not concerned with things like COM/OLE, so a lot of infrastructure for it not there. Mostly close

Q: What about in memory stability of objects (in ST - what about CLR?
A:What do you mean by that? Important to have type safe memory? Yes. The CLR should never corrupt memory.
Really talking about productivity/interactivity of objects during runtime (image, etc)
A: We don't do that (image) now. Statement that the image can be brittle. Uses PARTS (originally built for OS/2) and portability as an example.
Question is really about interactive development (workspaces, etc)
A:What is the state of the application that you want to persist? Hmm. I'm not sure he's answering this... Question - can you modify the code while it's running? can load classes. What about shape changes? My question - the blog server - patch on the fly. About state changes - Apparently, ASP.NET has some facilities in this direction, but it sounds complex and sounds like it only handles things forward, as opposed to extant stuff in memory. I think the short answer is "No"
Q:What do we do to survive in the CLR world?
A: learn to live with the CLR

Q: What is lacking in the CLR to support Smalltalk?
A: Tag typing support so that Smalltalk's object model could work. Says that Anonymous delegate stuff will help. "Intermediat late binding" support - Not good support now, needs to have it for good Smalltalk support.

Q: To make Smalltalk work and play in .NET, does it need to be type capable?

A: No, but it needs to be type aware. George related some early Smalltalk/V work in that direction.

Heh - comment from a Smalltalker doing VB.NET on the IRC channel: "I'd say it's about as good as you'll get at putting objects on basic, but it and .NET strike me as rather Rube Goldberg-esque"

Online at the show, or interested in what's going on? Join us on the Smalltalk IRC Channel and listen in!

The room is really filling up - we are getting ready for Sam Shuster's Pollock talk. Sam starts out asking which Smalltalk people are using - most of the crowd is using VW and/or VA. There's a lot of former VSE users here as well. Why is he asking? Because Pollock has borrowed ideas from all the major Smalltalks, from Delphi, and a variety of other systems. The ideas behind Pollock have all been validated (in part or in whole) in other extant windowing/UI systems. So how did Sam get into this? He interviewed with Cincom (5i.1 timeframe) - he was asked what he'd change if he could change anything? He answered: "the GUI! it sucks". Now, he admitted to no actual experience in building UI frameworks - lots in using them, but not in building them. So he was hired, and told he'd lead the GUI project :) So to backtrack - in the interview with Glenn Krasner, he draws a diagram of MVC, crosses it out and says "this is stupid!" - mind you, Glenn had co-written one of the original MVC papers with Steven Travis Pope - so the rest is history :)

What this is about is a roadmap - in the 45 minutes, we are going to be told how we can move forwards towards this admittedly disruptive technology. Pollock goes into "Production I" in late fall.

Q: Which hemisphere?

A: The only one that matters!
laughter

Pollock will be made available outside the scope of the VW release cycle. What's done?

• Widgets
• XML and L.A. Spec
• Code building frameworks
• Windows 9x/2k/ME, Motif and Mac OS X looks
• Wrapper features: 80% done - when Pollock ships, it will be feature complete compared to existing features
• No tools - framework only
• 13,992 SUnit tests

What's left?

• The little stuff
• feature match
• promises
• bugs
• Medium stuff
• API cleanup
• Internationalization support
• The big stuff
• tab order ~= Z order
• Smart invalidation (flicker free - No flicker in Pollock)
• No direct GraphicsContext writes
• Smart clip all invalidations
• New multi-rectangle damage
• Double Buffering - default on all platforms except Win 98/ME (due to resource constraints there)

Here we went into a long sidebar on the way invalidation and painting will work in Pollock, and how and why it will fix flicker issues.

What's it got that wrapper doesn't?

1. Auto look change (all widgets - no code needed from you)
2. Dynamic scrollbars
3. XML or Literal array specs - or build by code
4. Global drag/drop (not OS level)
5. Trigger Event system (no change/update)
6. Better look emulation
7. E-Z Extensibility
8. Consistent API
9. No Wrappers
10. A Future!

When Pollock gets to be the defaukt UI, the existing framework will be softly deprecated - available, but not pre-loaded. Another thing - code will be pushed out to the public store on a regular basis as we move towards release. Highlights:

• TextEdit - save and load in XML with emphasis
• grid - emphasis by row and column and cell
• Grid - resizable rows
• Frames - relational
• Aspects not required - will work automatically
• Rich API - directly on the widget
• Hotkeys - by look, image, UI, or widget
• Tab Control - optional tabs
• Toolbars - input fields and drop down list

Conversion Tools

• Convert Menus
• Convert Toolbars
• Convert specs
• Convert ApplicationModel code and translate to Pollock UserInterface code
• The rule - 80/20 80/20 rule. 80 percent should convert right off. The last 4 percent is going to have to be hand transferred.

Futures

• TextEdit - Hypertext
• Windows XP Look
• Listbox inline edit
• Grid
• Any widget in a cell
• TreeView column
• Different selected and unselected row views
• Smart fly by help (proper list support, etc)
• BGOK/Charts

After Pollock - Chagall

• Native Widgets
• Plug and play - emulated and native together
• Expanded Native Widgets
• Mac OS X
• Windows 9x/2k/Windows .NET Windows Mobile
• QT (KDE)
• GTK (Gnome)
• Motif/CDE

After Chagall - Peaches

• Graphics engine moved from the engine to the image
• GraphicsContext in image
• New Platform Portable Font System
• Event Loop in Image

Q: What about Doc?
Working on doc, there will be basic framework doc for production I. There is more information on Sam's Blog. This series will be continuing.

Q: 2D drawing API and translucency?
Translucency should be in the VM for 7.3. 2D model same until native widgets

Q: Events same as VSE?
Same - same as VSE and VA (whicg was "stolen" from VSE in the first place

Q: Can widgets be laid out in relation to each other?
Yes, using relational frame

Q: VisualWave? What about that?
Will remain dependent on the old GUI framework. The XML specs in Pollock would allow for XSLT to do some magic - talk to Michael Lucas-Smith

Q: Why the name?
Named after Jackson Pollock (the artist) - inspired by the name of the (never shipped) Van Gogh project. Chagall - native widgets - Peaches - Frank Zappa

That's it - we are over time - 20 minutes to the keynote with George Bosworth.

Len Lutomski talks about load balancing and Opentalk. Starting out with a demo - the demo is running:

• On a single host, multiple images (simplicity of showing it, not a limitation)
• Test Coordinator running distributed SUnits
• A Server Monitor that shows the message backlog

There are a number of load balancing algorithms implemented - one thing to notice at start is that things start out a little slowly as the various images negotiate their roles and set up. For the same reason, shutdown can take a few moments as well. The fist demo - a sequential round robin example. The monitor is showing an even load across all the systems as they run - exactly the way you would expect a round robin to run. Question from Len - which will distribute load better - a random round robin, or a sequential? Something for us to think about as he gets ready to run. The sequential distributed pretty evenly. There are some useful statistics available from the clients and servers - how long (aggregate) requests queued up, etc. Random round robin does worse, as the random assignment sometimes tosses "too much" load at a single server. We are actually seeing that in the monitor.

Next demonstration - "least loaded" scheme. As opposed to the round robin scheme, we need stats from each server about their load - so that we can make a determination. "Least Loaded" tends to drop load on a given server in sequence until the data about server load is updated. So a given server is in the "give me load" state past the point where it's no longer the least loaded system - we are making determinations based on old data. I've seen this personally - I implemented (with Sean Glazier) a simple load balancer for VisualWave years ago - the customer wanted least loaded, and we saw exactly what was just demonstrated. They ended up using our simpler round robin scheme :)

Now Len's showing us some kind of request stream that - using sequential round robin - tends to load down individual servers. Now he's going to use the same stream of data, but a random round robin. This is tending to work out better in terms of overall load - individual servers are not getting bogged. Now on to "Least Loaded" - This works out better than the round robin. (In reality, you should run lots of tests). The difference here is that the time to run the requests varies - instead of each being the same, each varies between short and long. Under that test, least loaded does ok. Now a round robin where the interval to switch servers has been set longer. This does tend to load a given server every so often, but in general distributes the load pretty well. By playing with the time interval to switch servers, you can get better (or worse) performance. There are various schemes for Least Loaded that back off - for instance:

• take in load data
• on request, pick lower half of group (on load)
• assign request randomly in that group

Works better than least loaded by itself, but does add complexity. Not only does it work, but it's fun to play with! Now back to the presentation

Load balancing is for syncronous, connection oriented protocols. For Multi-cast, you do something else. Some routers do load balancing - they are faster, but usually less flexible than software balancers. What about things (like web requests) that need to "pin" a server for session oriented requests? You have the balancer work only on initial requests, not on the rest. Why do we do this at all? We do this in order to minimize the time that clients wait on a request. There is overhead to this.

You really need to look at how long your requests tend to take in order to set up an optimal number of servers to use in a balancer - bearing in mind that the balancing itself has overhead (more network traffic, processing time for the decisions, etc):

• Redirection overhead
• Messaging overhead
• Hindered server and balancer responsiveness

Opentalk balancer - released as of 7.3. Four parcels, a framework built on Opentalk. And it's dcumented! There's an API defined for configuring and creating instances of components. Basic support for multiple balancer architecture, and generic clients and servers. Working on the failover and state replication issues.

Supported architectures - Again, not dealing with multiple balancers. The basic assumption is that all servers will deal with the same kinds of requests, and that all servers are the same kinds of systems. You should not use an architecture with sessions or transactions - i.e., any situation where you expect any maintenance of client specific, server side state between consecutive requests. So:

• balancer always, no loads
• client reference wrapper only holds a balancer reference. Goes to balancer for each request. balancer has a static distribution policy. Servers do not have co-located load monitors (not needed). Simple strategy, expensive in redirection overhead, cheap in messaging. Works well with no sessions or transactions
• balancer rarely, no loads
• balancer always, with loads
• balancer rarely, with loads
• balancer rarely, with loads
• no balancer

And we are out of time! Lots of good info on balancer strategies.

Day two is getting underway - we're all at breakfast downing large volumes of coffee. I'm trying to decide what talk to go to first - either Avi's O/R talk, or an Opentalk discussion. Decisions, decisions...

Joe Bacanskas talks about WAMU's experience moving an application from an Oracle back end to a Gemstone/S back end. WAMU got their first ST app (Loan origination) deployed in 1996. very successful, gave them a big advantage. That got Smalltalk approved to build a huge new framework - VisualBanker. The bank has 25,000 deployed Smalltalk clients. The bank grew by absorbing other banks, and got a large number of departmental apps - they needed to replace these with standard apps - and these have been Smalltalk front ends to Oracle. The application Joe is going to talk about is a Fraud prevention and loss management system - with about 200 users, built around 1999. VAST front end, Oracle back end. The application had several problems - the users generated the requests to improve this application, and a decision was made to move from Oracle to Gemstone:

• Cost of changes was high
• Cost of consultants needed to change the application was high
• The application was slow

Technical drivers?

• Application was brittle
• Application was buggy
• Application was hard to change

The recommendations came from a team of three developers who looked at the problem. The first recommended Gemstone instead of a persistence framework. The second developer used TDD, and had a high reputation within the bank. The third developer was in charge of overall design - "Domain objects should not have behavior" that was his mantra. This led to multiple layers of Mega objects that actually defined the behaviors that the domain objects should have held (led to complexity). This same developer did not like named instance variables - so most of the core domain objects were implemented using Dictionaries. The application was designed to be an N-tier application using SST (IBM's server layer in VA). This was to happen on a WAN using 4mb token ring..... It became clear that a distributed application was not going to perform. A 2 month death march landed all the server code into a really fat client.

The users eventually demanded a performant, better working application. Joe was eventually asked, and he recommended a port to Gemstone/S. He eventually got hired in to do just that. What did they have to do?

• Client
• Application server interface management
• Domain object change management - made somewhat more complex by the tie (at the far back) to an Oracle based Data Warehouse as the repository "of record". Used Gemstone code to push that stuff
• Reporting
• Oracle
• Behavior removal
• Client connection reduction

What was hard?

• Team did not share a common understanding of
• How the application worked before
• How to build proper interactions with Gemstone
• How Gemstone actually works

Scary statement by one of the developers just getting into Gemstone? "It doesn't work that way? But it should work that way!"

How much data? There were 60 million rows of data in Oracle - needed to move that to Gemstone and make real objects. The fastes load time was 4 1/2 days, but the maximal window size was 3 days. That was using a gigabit connection with nothing else happening on the machines in question... It took a lot longer than anticipated. Lots of battles over technical design. The long and short of it was - it didn't work. They ended up taking a subset of the data from Oracle into Gemstone. They built failover to go fetch (un-archive) data from Oracle to Gemstone on demand. Of course, the old version was being changed as the new version was being developed. There were the typical bugs in the new application, those were (eventually) found and fixed. The team had to work around a major GS bug in indexing - required late redesign, which resulted in a business function slipping the first release.

Now the good stuff :)

• Development/Deployment is much faster
• Changes take weeks instead of months
• Emergency fixes can be applied to the server in real time
• Application performance is much better
• Every aspect of the application is faster
• Processes now run on the server in 1/10th the time
• Server side behavior
• Business rules are being concentrated
• Change is extremely simple and straightforward
• Simplicity
• O/R mapping mostly gone
• New functionality simplified
• Where is the application going?
• Lots more automation
• Hundreds of new users (projected)
• Web interface (projected)
• Additional domains to be added (projected)

The main thing - The end users are happier

Question: Why can't you use an off the shelf system for this? - it's a unique system, nothing like it to be bought
Question: What are you still using Oracle for? - Don't want all the old (legacy) data to make the move from Oracle to GS. Reporting is solved by having Oracle.
Question: What will you do when you cross the 1 billion OOP mark in GS? - Actively archiving. 64 bit db would solve this for them... There are other solutions (multiple db's, etc).

I just got an email with this information on "The Return of the King" DVD. Theatrical DVD - May 25. Extended Edition - Christmas...

Georg Heeg discusses the idea - can we keep doing high value development in the West? Why are people looking at offshoring?

• Cheaper

What are the disadvantages? Typically, need to be very specific with your specs. Run the risk of having high skilled people (who can afford high value goods) be unemployed. Georg relates the experience of the textile industry in Germany in the 60's - the work moved further offshore, with production in Germany moving "upscale" - higher quality, luxury goods stayed, while lower quality commodity goods went. How does this translate to software?

• Need to develop and adapt software very efficiently
• Need to remain customer oriented

Software industry in Germany lost 80k positions (10 percent) in the last year. Those jobs will not be back - they are commodity jobs that left permanently. We need to create new jobs to replace the lost ones. What does that mean - don't work at the low level - think like an end user. The amusing thing? These next slides are actually old - Georg used them to introduce OO to developers as far back as 15-20 years ago. In other words - the values we have been preaching in the Smalltalk community are the ones that developers need to stay in business.

History - Smalltalk-72 at Xerox PARC. The goal? To create the DynaBook (finally starting to get close with PDA's and Tablets). Then Smalltalk-80. First published in Byte Magazine in 1981. This is the technical base of VisualWorks (and Squeak) - in fact, everything that continuations make possible was invented in this system - and the supposed "modern" systems (Java, C#) - still can't do it. Commercialized at PP in the late 80's, Large projects started in the early 90's, IBM got in the game, many Smalltalk books appeared. Then Java appeared and PPS made many bad choices. In 1996-1999 - many of these large projects went into production - and most end users liked what they got. Cincom took over VW and stabilized VW and OST. Starting in 2003, things started to turn around. New Smalltalk users, a change in the business (.NET), new Smalltalk books are being published. Alan Kay received a few awards, C'T magazine (Germany) started a Smalltalk series, sold 380,000 copies.

"Smalltalk is a modeling language" (Adele Goldberg). There's a lot of FUD pushed out about Smalltalk - "The farmer will not eat what he does not know about". Now, Smalltalk is different. However, you won't stand above the competition merely by "keeping up with the Joneses". To "get" Smalltalk you have to unlearn a lot of the baggage from other languages - it's "too simple". Smalltalk enables things like Seaside - the productivity is just higher. So is software development still feasible in the developed world? Yes, but only if you move up the productivity food chain. Finishes with an invitation - to ESUG in Germany.

XML On the web - where it's going. He's talking about his company, Wizard Information Services. Located in Canberra, Australia, started with VisualAge Smalltalk - has been doing so for 7 years. They were sold on Smalltalk originally by IBM, but all the IBM people now push Java. What did they start with?

WizDom

• Core Framework
• Object Oriented
• Pattern Oriented
• "Naked" Business Objects

Mavis

• Merged Audio/Visual Information System. Major customers:
• Library of Congress
• AMPAS (Oscars)
• Bundesarchiv
• National Library of Norway
• Screensound Australia

MetaWizDom

• Content mgmt and bsuiness transaction system
• Running over 35 websites for Australian govt entities

MetaGrants

• Govt grants mgmt system
• 2 customers - Brisbane City council, ACT government

All Communities Online

• online communities - like Ezboard, but govt/community oriented
• Make simple pages online
• publish events
• Categorized
• Used by ACT government - over 1000 community groups

Goals

• Web Enable all applications
• X-enable every application
• Interfaces to and from external systems
• Expose "naked" business objects using trusted APIs

General Goals

• CRUD apps (plus search)
• Achieve "browser based" UIs as well as traditional GUIs
• Reuse "web" technology
• Open

Architecure

Here we have a picture - client tier - WithStyle. Middle Tier - VW and VA apps. Why HTTP and XML? Well understood, everyone has it, XML can be dealt with regardless of implementation language used by others. Easy to read and debug by a developer. XSLT? Lots of knowledge in house (Wizard). Well supported by Cocoon and WithStyle. SOAP? industry buzzword. Works better than XML-RPC, well supported by VW and VA. Most developers at Wizard prefer HTTP and a "REST" interface. Apache Cocoon? It's the web publishing framework they use. Based around XML. Supports HTTP, XSLT, and SOAP. Something well done in Java. WithStyle - written in Smalltalk (VW). Can talk XML to the server rather than HTTP. Richly supports HTTP, XSLT, SOAP, REST, and Smalltalk. Great UI experience.

Database to Objects? Using Toplink (VA). Moving to GLORP. Almost enough information in their descriptors (business level) to generate an XML Schema. Downside - XML Schema does not map well to Smalltalk OO designs. Very large and cumbersome. Is barely machine usable - don't want any actual people looking at it :) SOAP doesn't equire it - industry wants it. They generate it, since it's such a PITA. They use the descriptors from their db layer to do so. Basically, use the "meta" information for one transform (object to db) for another (object to xml). Good thing - VW and VA both have SOAP frameworks. They have business objects already - they translate SOAP into Smalltalk using XSLT. Quote:

It's not as disgusting as it sounds

ST Server - take request, translate into a SOAP request. Turn SOAP into Smalltalk. Execute the Smalltalk. Cocoon deals with the ST server for back end services. Validates user id and passwd via the ST server. All requests to the ST server ae done with the session ID and the user ID. HTML Forms? Template XSLT for making forms, ST Server transforms the HTML form value pairs into a SOAP request, which then goes through the normal execution path.

Ahh, a demo. He's got Cocoon running in the background, a VW server, and a VA server. Going to the Smalltalk server directly yields an XML doc. Going via Cocoon round trips to the ST server, uses Cocoon to apply XSLT to it and display a web form. Some nifty stuff in the demos, again.

The web devolution:

• The culture of the status quo
• Web Tech immature in many areas
• Yet to see mature, convincing XML solutions
• Lack of rich interaction with XML at the client
• Poor non-technical XML editors

Where are we? Enterprise apps are becoming browser based. XML is everywhere, web svcs are here to stay (ed. - adoption is still slow though). SOA is emerging - IBM is focusing WebSphere on this. Few client side solutions - most are on the server.

We are "stuck" with browsers. Inferior scripting languages, black box development. Mozilla is huge - bloated. Browsers are designed for read-only viewing, and only deliver a low quality experience to the end user. Usability and productivity are low - everything requires the page/submit mode. Great Forrester slide showing evolution fo applications from mainframe to client/server - and back down the scale for web apps.

What rich UI options are there?

• Flash based UI
• Java Applets
• ActiveX
• Mozilla (XUL)
• IE behaviors

Or WithStyle. All Smalltalk objects, XML direct to the UI, completely open and flexible. The inspiration for this? Twoflower browser from Holger. It has a small code base and is open. Is solving a simpler problem (HTML4, no CSS).

Analysts:
"The Web cripples usability. Executable internet technologies will help companies return responsiveness and productivity to Net based apps"
And more like this - the basic message - we need network applications that aren't brain dead. We need the best of both worlds. Nifty - the presentation is XML/CSS presented in WithStyle.

Rich internet apps

• Desktop app capabilities
• Client side power
• Rich UI possibilities

Advantages - more responsive and productive than browser based apps, but with the reach of an internet application. Workflow is simpler, as the state is on the client. No bulk submit for refresh, makes for faster response times. Allows for offline work, P2P, etc. Smalltalk is the perfect choice for all this. WithStyle has been a little more than 12 months with 2 and change people. What's the opportunity? A fresh slate for reinventing the browser paradigm, designed for applications. Makes it possible to make Smalltalk more mainstream. All of the session/state issues go away.

And now a demo from Michael. He's introducing the WebUI from WithStyle. Rich internet app, completely open to extension. Styling with CSS is only a start - integrating with Pollock, XForms, advanced widgets. One goal - complete GUI UI's that are skinnable with CSS. Why CSS? It's a powerful layout language influenced by traditional publishing. Separates presentation/content. For an example of this - see CSS ZenGarden. What examples? An example web browser, development tools, an XML editor, and an XML powerpoint replacement (being used in this talk). For all this:

• Developer program starting soon - sign up at the show (NDA)
• Nightly releases began 20 February 2004

What does the example browser support? Charsets, scripting, XML Events, better layout and CSS support, XML Schema, DXML (DHTML), XSLT, Basic Tables, Basic Embedded Widgets, Editing, moving to Pollock, thin client. Over 600 tests, 5200 methods with around 35k code. Now the demo - he's showing off WithStyle showing http://www.w3.org. Next, CSS ZenGarden. Well, we got the typical demo MNU there :) Now on to editing. The XML editor is a WYSIWYG editor - very impressive. Next demo - creating a slide presentation directly - add a class, add some xml and html in methods - and we can launch it. This part you really had to be here for - it's all demo code being written on the fly. Very cool demos.

The first keynote - Avi Bryant on Seaside and redefining web development - using the strengths of Smalltalk.

First thing to address - why bother? Web apps are really clumsy things - they aren't easy to write, and they aren't easy for people to use (limited widget sets, HTTP for interaction, etc). Oh god - I've been quoted:

I'm more of the mind that HTML based app suck
James Robertson

Applets haven't worked out - users had already figured out the "mental model" of the web - website feel, hrefs, back buttons. So while Java applets have mostly failed, Java has succeeded wildly on the server side. Meaning - server apps are a "second chance". Paul Graham and his web store (sold to Yahoo) is a great example of that. Why did he use Lisp? "Because he could" - on the server, no one knows if you're a Lisp app. The image based nature of this made it possible to do things that simply cannot be done in (Java, .NET, etc).

So why should we, as the Smalltalk community - care about web development? Because there's an "unfair" advantage on the client side. On the web, none of the issues (native widgets, platform integration, etc) matter. Instead, you can leverage Smalltalk's strengths directly. Writing web apps is hard - Smalltalk makes it easier.

To start - short history of web apps:

A collection of functions that take HTTP requests as input and produce HTTP responses as output

This is a lot like shell commands and pipes, actually. The basic problem is that HTTP (and thus web apps) are stateless. This works fine for simple applications. Any moderately complex application does, in fact , have state. Simple E-Commerce example - shopping cart, get billing/payment info, verify with the user, process, ship. Lots of state here. How dooes that state stick around? It gets shuttled back and forth from client to server (hidden fields, cookies, url arguments, whatever). A lot of code gets written to deal with this state passing issue. It's hard to generalize this too - it varies too much by application and domain.

So now we get into session management - when you first start an application in the browser, you start a session. When you quit (or timeout), you leave the session. You need to pass the session id back and forth so that the server knows which session you are coming from. So why is this a problem? You pass new data back to the server, and the id - and the server manages the rest.

Why global session id is evil
You start with (Expedia, say) - and spawn a new window to look at options, use the back button, etc. You stay in the same session. You have to be very careful to go back to the right place or you get the wrong result. I can vouch for that - many, many server apps don't deal with the back button at all well. WebObjects did this a little differently - it gave out instance based id's (not global) - this ends the confusion as to "where am I?" What's the problem here? Coupling. This still gives you rigidity in the ordering. It's just a repeat of the mainframe green screen issue - you get forms in the order you get them, and changing the order requires a massive change to the entire system.

Seaside is to most other Smalltalk web toolkits as Smalltalk is to most other OO languages; it's as simple as that.
Cees de Groot

The thing that gets hairy here is conditional flow. How do we move from one part of the application to another outside the standard procedural flow of a web app? One possibility is a set of blocks, one for each possible step. We just ask each block to evaluate itself as appropriate.

checkoutProcess
	^ShippingAddress new next:
		[:ship |
		BillingAddress new next:
			[:bill |
			paymentInfo nnew next:
				: [:bill |
				ConfirmationPage new
					shippingAddress: ship;
					billingAddress: bill;
					paymentInfo: pay;
					yourself]]]

This is sort of continuation style - you pass blocks in, and changing the order can be done in one place, and one place only. Still too rigid.

checkoutProcess 
	|pay ship bill |
	pay := self call: PaymentInfo new.
	ship := self call: ShippingAddress new.
	bill := self call: BillingAddress new.
	self call:
		(ConfirmationPage new
			shippingAddress: ship;
			billingAddress: nill;
			paymentinfo: pay).

The idea? What if execution were "frozen" at each step? This is much easier to write, and makes the execution order much easier to see (and change). In a sense, what we've done is return to a "line oriented" screen application that "waits for input" - which is how end users expect to interact with web browsers. The user can use the back button and rewind the application (as you can in a Smalltalk debugger). This really extends the power of Smalltalk from the developer to the end user in a way that allows for natural interaction by the end user. The context stack is being copied and preserved on each submission. Based on some questions, Avi demonstrated following both possible paths down a web app by cloning a browser page and executing both paths. Now, you can protect against that in cases where it's necessary - there's a way to isolate calls - you'll get redirected to the right place.

self isolate: [self call: PaymentInfo new]

Question: What about the cost? The contexts that are being kept around are expoired (configurable) - generally, only the last N are kept around. The bottom line is, Seaside is memory intensive and trades memory for performance and ease of use - not to mention time to deliver.
Question: What about session identity in a multi-server environment? that's already an issue, and is typically handled by pinning a user to a given server (this is how most load balancers deal with this). Question: Temporary vars get saved on the stack - what about other stuff? There's a general mechanism for objects that need to be backtracked (a shallow registry of objects that need to be rolled back). You can customize this to handle whatever needs to be held for rolling back. So you want to roll back UI state, generally not domain state Question: Any issues with multiple sessions trampling on state? That's an application issue. You still need to be aware that you are writing a server application...

So Avi shows us the implementation of a Continuation. In Smalltalk, a Continuation is 10 or so lines of code. It's pretty simple code - you serialize the stack and save it off. Invoking a continuation is a matter of terminating the current context and then restoring the one in question - and then swap the sender out. Question - the context termination will not call the #ensure blocks. This is a thing you need to deal with - make sure that an #ensure does not go across multiple continuations. The interaction of #ensure: and Continuations is not a solved problem. Lisp has exactly the same issues.

Question: could you use a "prevlayer" type approach to serializing stuff out for failover? Yes, but you need to be careful - continuations contain compiled methods, etc. Could be done, but could be complex.

General laugh - with 15 minutes remaining, Avi is moving on to the second half of the presentation. Many good questions in this session. So now on to rendering HTML.

Web heresies - the ID (opaque) in the URL. Another one here - generating the HTML with code (however - the Naked Objects movement wants the same thing). I suspect that the problem is simpler on the web. There's an answer that works better - you have the framework generate simple HTML, and then have CSS render it in a nicer way - this still achieves a separation of presentation and domain. So you do have templates - CSS

Where has this been ported?

• Squeak - main development
• VW (public Store)
• Dolphin - not recent, but possible
• VAST and Smalltalk/X - not possible, as you cannot copy the stack.

Doc - attend the tutorial :) There is an active mailing list. There's also Avi's blog

Martin Kobetic on cryptography in VW. Why use cryptography? All the basics - confidentiality, integrity, authentication, etc. Basic definition - Combine plain with some algorithm to produce the cipher, which can then be reversed to get the plain back. What all encryption algorithms are attempting to approach is the security of one time pads.

Symmetric Key ciphers
Bulk data encryption - built to be fast. There are two basic types - stream and block ciphers. What's a stream cipher? A time varying transformation on individual digits. Examples are Pike, A5, RC4, SEAL. RC4 is one of the most popular. In this kind of system key re-use is catastrophic - it allows any attacker to break your cipher easily. What you need is a (close to) random key stream generator. Nifty - as a demo, he selected a portion of the slide and encrypted it using RC4 (the presenter is a VW app). Wow - encrypted two parts of the slide with the same key, then overlaid them and XOR'd them - you get two plaintexts over each other.

RC4
heavily used in web interactions (fast). It's the leaked trade secret of RSA. Much, much faster than Blowfish.

Block Ciphers
Fixed transform on blocks (64, 128 bits, for example). DES, IDEA are examples. DES is the best known of these - now 20 years old (even though initial life span estimate was 5 years). Triple DES is still approved, single is legacy - too easy to break. One of the things to keep in mind - you have to encrypt a multiple of the block size as input (you use padding). Don't use the simplest method (splitting text into proper size blocks). His demo onscreen ended up with a readable block that had a color overlay. There are various block modes that should be used instead. His demo here ended up with a nicely opaque block of the screen. There are block modes implemented as polymorphic wrappers in the VW library. Again, key reuse is catastrophic!

Other supported - AES (DES replacement), Blowfish)

Public Key Ciphers
Public and private keys. Hard to compute private from the public. Tend to be slower than Symmetric ciphers. Used in Digital signatures - RSA, DSA are examples.

Hash Functions
Unlimited input size -- goes to gixed output size. Often used for "data fingerprinting" and validation. We implement MD5 and SHA. MD5 is very common

• One way
• Collision resistant

Message Authentication
Usually use a Message Authentication Code (MAC) - a hash function with a secret key. Hash a key, hash the data, concatenate the results, hash again (HTTP Digest Authentication is a variation on this).

Digital Signatures
Reverse application of a public key cipher. RSA, DSA used for this.

• Signing
• Hash the plaintext
• encrypt the digest with private key
• Verifying
• hash plaintext
• decrypt with public key
• validate

Diffie-Hellman
Allows you to safely pass data across an unprotected channel. The two sides negotiate in public, and then establish a secure channel.

Question: do we have what's required to support Open PGP?
Answer - not yet, although there is some code in the Public Store. Basically, the expected file formats would need to be supported
Question: Obsolete - are there found weaknesses, or faster hardware?
Answer - Both
Question: When do you expect to write your interactive book on this subject? It's better than any other explanation I've seen
Answer - This is the first presentation of this since martin started working on this. It's a lot of work - no answer :)

Question: Why did we do this natively in VW?
Answer - wanted a native SSL implementation (X-Plat)

Lots more stuff - Martin had more material than time.

SRP talk by Paul Baumann. Why SRP instead of XML? Simple - do we want text editors or object inspectors? Text is easier for people, but harder for computers.

Binary Encoding issues:

• Limited portability of basic data types
• Fixed Width, hard to migrate

XML Encoding

• High portability of basic data types
• No fixed width issues
• reformatted data can still be parsed

SRP

• High portability of basic data types
• Simple parsing rules applied to a stream of unsigned integers in a range from 0 to infinity
• Object State can be loaded regardless of schema/behavior changes

Traditional binary encodings offer good performance but are brittle. XML addresses this, but at the cost of performance. SRP tries to offer both. Has been ported to all major dialects, and works on them from a single code base. Managed from a single Smalltalk image in one dialect, exported out. The modules:

• PlbStateReplicationProtocol
• The core
• SrpPortableObjects
• Dialect specificity
• SUnit tests

So on to the demo - from Dolphin Smalltalk. The code is being loaded into a clean Dolphin image - nothing up his sleeve :) There are various configurations possible (and creating new ones requires only that you specify the encoding) - so you can do Base64, etc. So what has he done - from Dolphin, loaded a complex object (a class) from disk - the class did not exist in the Dolphin image. Then he dropped it back out, quit Dolphin, and fired up VA. Now we are looking at the portability layer - he's made sure that all class extension methods are named (with an srp prefix) such that collisions are unlikely. Interesting - he came up with his own placeholder concept instead of using #become:, as it's slow in some dialects (VA, for example). Placeholders are really just domain specific become-like behavior. Now, loaded the complex object saved from Dolphin, and there it is.

Questions
What are the applications of this technology?
Being used by a few people, have not been many releases of it

Why use this instead of BOSS?
With BOSS, you write directly to a stream - if the behavior of your objects changes, might break. Also uses #perform:, which makes it potentially fragile. SRP doesn't execute anything based on what you've loaded. Each dialect does have it's own tool for this - some are faster than SRP, some are slower. SRP is more space efficient than most. The main objectives are space efficiency and portability.

Blocks?
There's VA support not ported. Should be easy enough

What about shape changes?
First thought - loader for handling that. Current rev supports version info stored along with it (BOSS does that, and supports schema migration...)

SRP is open source under the Mozilla license.

This could be useful for people contemlating a migration from one Smalltalk to another - especially if they are using a dialect specific way to save objects to disk - by using SRP, those legacy objects on disk could be pushed across the divide. For that matter, it might well be useful in upgrades (for instance, from VW 3 or earlier to VW 7.x) - where changes in the dialect between versions causes problems with the legacy objects on disk.

Well, I'm up for the first day - a little groggy, but up. I have to get to a meeting of all the Cincom folks at 7:30 AM (grrr - that's coffee time!) - but then it's off to the talks. It looks like we won't have net access during the show - the hotel wanted absurd amounts of money for that. I'll be taking notes and pushing stuff up when I can though.

The PDP has been part of VisualWorks since the 7.0 release, but there are still things about it that not everyone understands. In VW, prior to the PDP, it took a halt in code to jump into the debugger - now, of course, you use breakpoints or watchpoints. That's pretty well known now - but being able to debug any arbitrary process in the system isn't so well known. Here's what you do:

• From the launcher, pull down the Debug menu (or hit ctrl-y)
• Select Process Monitor
• Select a process
• Pull the Process menu, and you can debug (or inspect, or terminate, etc) the process.

It's a simple thing - but very helpful in an application that's running multiple processes (like, say, a server). I've made use of this facility in the development of BottomFeeder and the blog server.

Scoble gets this wrong, I think. he points to this article which states that blogs are too permanent for executives. Scoble says that's hogwash, but I think he's wrong - at least for execs in publically held companies. Look at all of the Sarbanes-Oxley (and related) rules that have come down the pike - it's gotten to the point where a C level exec in a public company has to be very, very careful with his public statements. I can definitely see a lawyer advising an exec against making off the cuff statements in public...

In an SDTimes article, Andrew Binstock shows that minimal research is just beyond him. He's correct about the uptake of XP in IT shops - it's not a commonly used methodology. A lot of this is cultural - management likes paper trails, and the popular RUP guarantees lots of it. That's not the rathole Binstock runs down though - in talking about XP, he says this

Second, XP was embarrassed by the cancellation of the C3 project at Chrysler. This project was the poster child for XP. It was begun in 1996 with the mission of getting Chrysler's payroll off its mainframes in time for Y2K. Kent Beck, the father of XP, was brought in , and he implemented XP and made the project a showcase of the new methodology. Alas, Chrysler cancelled C3 in February 2000. The deadline had been missed, and the mainframes were still cranking at full tilt to handle Chrysler's payroll. With Beck running the show, there is no wiggle room for asserting that XP wasn't done correctly.

I guess Binstock's a busy guy - because he clearly didn't contact any of the people associated with that project. I've spoken to many of them, at different times and in different places. The C3 project went down for the same reasons that most IT projects go down - politics. I'm sure that SDTimes provides internet access for the staff - Binstock could have googled the email addresses (or even hunted around the C2 Wiki a little) and found this explanation of the issues. I guess it was easier to throw rocks at something he doesn't like though - facts would just get in the way...

This week, InfoWorld has a cover story on XML and how well the 4 major databases (DB/2, Sybase, Oracle, and SQL Server) handle it. The part I'm commenting on is in the introductory paragraph:

If you could do one thing to improve integration and automate processes with customers and business partners, it would be to implement XML, which has become the standard for exchanging information between disparate systems because it is easily transformed into any format.

Sure it is. Assuming you know what kind of schema the document is using. Simple example - say you picked up an old version of BottomFeeder and were confronted with an Atom document. heck, suppose you had version 3.1 (version 3.4 is the most recent) and wanted to deal with an Atom 0.3 document? That rev of Bf had not dealt with 0.3 yet, and the 0.2 handlers did not display information from 0.3 documents correctly. Sure, you could translate an 0.3 doc back into an o.2 doc - but would you have any idea that you should?

XML is a data format. It's no better or worse than any other format, and it's certainly not magic pixie dust - and yet publications like InfoWorld continue to present it as some kind of magic interoperability balm, ready to smooth away all problems. It's not - if you don't know what kind of doc you are getting, you aren't likely to be able to deal with it intelligently - whether it's human readable or not. XSLT assumes that you have the semantic knowledge handy to a do a transform - the simple presence of angle brackets does not grant that semantic knowledge. Here's a nice example of the magic pixie dust thinking that pervades the XML world:

For example, querying on a patient ID number in a relational database may allow you to quickly find the dates a certain patient visited the hospital, the conditions he was diagnsed with, and the treatments he was given. But it likely won't help you determine which treatments were provided for which conditions, or what times the treatments took place, nor will it give other useful information that XML versions of these records could provide

Say what? has this guy never heard of foreign keys and joins? Sure, they can get messy for complex data retrievals - but they are hardly impossible. Reporting systems are being built to handle these sorts of issues all the time. And XML records would magically solve the problem? I'd really like to know how. Apprently, applying XML will make it easy for me to solve every software integration problem I have.

The most amusing part of this is the complete lack of historical awareness. Hierarchical databases were the storage solution until the 80's. At that point, the RDBMS started to become supreme - primarily due to the large amounts of flexibility in changing the organization of data - and the greater ease in creating ad-hoc queries. What's an XML database? It's a "back to the future" kind of move, that's what. There's nothing new here except the realization that hierarchical storage of data has merits in some domains. It's no end-all be-all - if it were, the old hierarchical databases never would have gone by the boards.

Scott Adams explains it all today. Heh.

I'll be off for Smalltalk Solutions in a few hours - I won't be getting to the hotel until after midnight (any night owls up for a drink?) My slides are actually done - you can have a look at them here. Should be a great show.

Chris Pratley makes some good points about the patent system. Well worth reading

Attention goodie submitters:

If you've got code that we are distributing as a goodie, we really need any updates you have ASAP! We are getting close to the VW 7.2.1 and OST 6.9.1 releases, and need to get this closed out. Please see:

http://www.parcplace.net/goodies.html

Scoble is showing that the ad budget at Microsoft is being wasted on the marketing department. I agree with him about that MS Office campaign - the people who came up with that should all be fired as a lesson to the rest of the field :)

Via Ben Hammersley I found this specification for yet another syndication format. While I understand what's being done here (and it certainly looks simple enough) - it looks a lot like a more highly specified RSS with slightly different tag names. I think I'll wait this out and see if anyone pays attention....

I was wrong. Tim Bray points to a - wait for it - HTTP over SOAP implementation. I'm thinking idle hands....

Somewhere out there, Michael Lucas-Smith is on the highway - trying to remember to stay on the right side :)

Internally, some of the non-Smalltalk groups at Cincom are using SharePoint (we use Wikis in the ST group). SharePoint seems like a natural for exporting RSS, and there's a free part for doing just that. There's a problem though - it generates odd RSS. It defines a namespace like this:

xmlns:rss="http://purl.org/rss/1.0/"

That namespace is the default namespace for the document, and none of the elements are in that namespace - which makes them invisible to BottomFeeder, which sees feeds from that tool as RSS 2.0. Never fear though - I added a handler specifically for SharePoint that expects this slight deviation and handles it. So if you use SharePoint, you can export RSS and have BottomFeeder pick up the results. There are a few commercial (i.e., paid) solutions for this as well; I have no idea what kind of RSS they pump out.

StS 2004 starts Monday - there's still time to sign up and get there. I'll be arriving late on Sunday - so I likely won't see anyone until then (unless there are some nightowls in the hotel bar on Sunday). It's going to be a great show - I look forward to seeing everyone there.

This story seems to recycle every few months in a "the sky is falling, the sky is falling!" sort of fashion:

Already, aggregators have swamped some sites, slowing Web servers and eating up expensive bandwidth, according to bloggers and other Web publishers. The end may be near, unless something changes soon, said Gary Lawrence Murphy, whose Linux blog, TeledyN, has been overloaded.

There's an answer to this, and it's called conditional-get. Browsers implement it, and it's not hard to implement in an aggregator - I added it to BottomFeeder over a year ago. I'd be curious to know which aggregators don't implement this, and why. This does lead me into another area along the same bandwidth related lines though:

The Atom guys have been (and still are) seriously considering the addition of binary data blocks to Atom feeds (music, images, video, etc). That's a nice sounding idea until you combine it with the way HTTP works. Say I add a 3 MB video file to my feed. Smart aggregators that use conditional-get will only get that data once - until the feed is updated again, that is. The problem is, there's no way to get a partial document using HTTP. That means that large attachments to a feed will be fetched every time a feed is changed. If you have a rarely updated feed, that may not be a problem. If it's a blog that's updated regularly, it's a problem.

The funny thing is, this exact problem is addressed by RSS Enclosures - by providing a reference to that sort of data, and allowing the client aggregator to grab the data in any way it chooses - some kind of background process, a simple link for the user to follow, whatever. That's the right way to do this, IMHO - the proposed Atom support is just a bad, bad idea in the context of HTTP.

Chris Pratley talks about blogging - and in the process of talking about Word, hits on something relevant to any blogger:

A couple of people have asked about the permanence of electronic information and access to it in the future if it is in Word format. Microsoft takes this very seriously. That's one of the reasons we make the format documentation available to governments and other institutions, so that there is no concern that they will not have the ability to access the information at a later date. Personally, I find this whole discussion a little bit overwrought though. If it is access to the content of a Word doc that is a concern, just about any word processor available today can import Word documents sufficiently that you can access their content. You don 19t need a Microsoft product for that.

I've talked about this before - anything you write on a blog should be considered permanent. There have been somewhat embarrassing disclosures of old draft information found in word documents - but that's nothing compared to the permanence of what goes on a blog. Ultimately, you just can't delete your content. Why not? Well, your content got cached all over the place:

• Feedster
• BlogDigger
• Google
• Gosh knows how many client aggregators

I fully expect to see political campaigns using this as oppo research in a few years - imagine the 45 year old candidate for some office being called on stuff he wrote on a blog 20 years back - still available through some kind of search service. It's not going to affect only politics, either - employers are already doing google searches for references when a person is being considered for a job - a blog is the ultimate paper trail. Compared to that, Word documents are ephemeral....

ABC News to Sun: Drop Dead. This summarizes their take pretty well:

It is no longer enough to blame the high-tech recession for all of Sun's blues; other companies - including some even worse hit, like Yahoo! and Cisco - are making strong comebacks.

Sun is not coming back. It is a giant company without a business.

That's pretty much been my take - they spent too much time fighting the wrong war (Microsoft), and too much money on a software business (Java) with minimal revenues. The deal with MS was a desperation move, not a masterstroke. Here's an email I just got from someone (this story was pointed out to me in email):

BTW, we have more than 1000 Linux blades in the business. Nobody here talks about upgrading expensive Sun boxes anymore.

That's not the only company I know of making that kind of call. Heck, our engineering group is looking at a new file server. The old one was a Sun box, and it's not looking likely that we'll replace it with a Sun box. It's a huge problem for Sun, and I don't see an answer for them...