Smalltalk Tidbits, Industry Rants

Chris Pratley, the Program Management manager for Word (amongst other things) discusses Word and its movement from "worst to first" in market share. It's an interesting read, and explains one thing very clearly (at least to me) - Word was a far, far better product back when it had meaningful competition. At this point, Word's developers have utterly forgotten what end users want, and it shows. What do I mean? Well, here's my list of irritations with Word - none of them utterly crippling, but the collection would make me switch products in a heartbeat if a decent competitor existed. Word Perfect isn't it, because it mostly stinks in the same ways (my Wife uses it).

It didn't used to be this way - I recall liking Word for Windows 2.0. It stayed out of my way, and did what I wanted. The current product mostly gets in my way, and does things I dislike:

• Bullets and Numbering - yes, I've mentioned this before. However, I shouldn't have to use copy/paste to ensure that a bullet goes where I want it. This part of Word is just broken
• Those adjusting menus - they drive me nuts, because all my learned behavior from older versions of Word is shot. When I pull a menu, the items aren't where I expect them - and often aren't there at all until I pull the whole menu. It ought to be easy to turn this off - but the options don't look obvious to me
• The HTML export - the HTML created is a mess. Does no one in Redmond actually know HTML? Based on Word, my guess would be "no".

Doesn't look like a long list, does it? It's not - but the mess with bullets ticks me off every time I use the product. It's a constant, low level irritation, just like the menu thing. The irritation is exacerbated by the knowledge that this stuff used to work - I know that I did not have to fight bullet lists every step of the way in WfW 2.0. It's been a downhill slide since 2.0, as far as I'm concerned - regardless of what the reviewers have said...

Holger released a new rev of Twoflower this morning, so I was able to update BottomFeeder to use it. This fixes some of the font issues (especially with bolded text) that had been present in the previous cut. I also received notice that Bf doesn't support urls that look like this:

http://username:password@www.somesite.com

That's shorthand for Basic Http Authorization - it's a way of providing the information up front instead of waiting to get prompted. The Http code wasn't parsing that out, and was instead barfing on that as an invalid url. I've addressed that in the latest update to the Http-Access module - that sort of url is now fully supported in the dev stream.

Many people have heard about the 1980's Van Halen contract rider specifying "no brown M&M" be present backsatge; here's the back story on that. Fascinating bit of trivia.

I'm giving a talk on the implementation of BottomFeeder at StS 2004 - there's still time to register, btw! Anyway, saying I'll talk about the implementation is a bit broad - what am I going to discuss?

I've now given a variation on this talk three times - to two STUG meetings, and at ot2004. The STUG talks were more technically oriented, but I got a lot of good feedback at ot2004 about it. So before I really get into implementation, I'll (briefly) do two things:

• Explain what a blog is - it's easy to assume that "everyone" knows what a blog is. It's still something of an insular world though, so I'll provide a brief overview
• What's an Aggregator? Again, as with blogs, not everyone knows what one is. I'll again give a brief overview of what an aggregator is.

Then I'll talk about how I stumbled into this field, followed by some of the implementation details of BottomFeeder. I've uploaded the slide deck here. I've made a few changes since I sent in the presentation for the StS CD, so it might be worth downloading. I'm speaking bright and early - 8:30 am on May 5th. See you there!

If you are flying into Seattle for StS 2004 and need a convenient ride to the conference hotel, then check out the Seattle Airport Shuttle Express - the fares and schedules are posted on that page. A cab will likely run you about $35 USD. See you in Seattle!

He may not know it, but Gary Short really wants dynamic typing. Just look at how C# makes him lie to the compiler....

Alan Green has some wild theories:

In a recent Charles post points out that it takes a lot of (keyboard) typing to iterate over a list in Java, compared to the same piece of functionality Ruby, Perl, Python, Lisp, Smalltalk, OGNL and Haskell.

It would only be a fair comparison is these languages were suitable for large systems development.

At the time Java was created, Ruby, Perl, Python, Lisp, Smalltalk, OGNL and Haskell were either non-existent or suffered serious deficits as large-systems programming languages - Back then, the in-vogue large-systems programming language was C++

Apparently, Alan Green is still in High School - he equates "in vogue" with "serious". So prior to 1995, Smalltalk wasn't suitable for large systems development? Oh, really? I worked for ParcPlace Systems back then, and between 1990 and 1995, lots of very large, very successful projects were done in Smalltalk - both in VW and VSE, and in the (then new) IBM Smalltalk. Many of those projects - at Fortune 100 firms - are still in production. It could be simpler than this - I suppose one could translate Alan's statement this way: "It's not fair to compare Java facilities to Smalltalk, because when Java came out I hadn't heard of Smalltalk"

Spotted in 0xDECAFBAD: You too can create your own reviews - and have them picked up by sources like Amazon (etc) - here's the RSS module definition for RVW. Interesting.

Colin Putney has joined the blogsphere with a SmallBlog - here's his RSS Feed. Colin's going to talk about Squeak Tools at StS 2004 - so there should be a lot of good info coming out on his blog. Subscribed!

The feed back for our last survey was great - thanks for all the great feedback. There's a new survey up, and this time we are interested in how you get information on Smalltalk and other products:

• Tradeshows?
• Blogs?
• Vendor websites?
• Community driven sites?

We would like to make things simpler with regards to getting Smalltalk information, but we need to know where you look now. Thanks in advance!

Interesting justification for log4J over on the manual site for log4J - an old quote from Kernighan and Pike related to C level debugging:

As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.

Now, logging is useful - I still do that with remote Smalltalk servers that have no UI from time to time. However, this makes it sound like logging is still preferred to debugging. Admittedly, the home site for a logging tool is going to be biased, but still... to my mind, logging is a poor substitute for using a debugger. Of course, a Smalltalk debuggeris actually a code browser with the context stack riding along, so YMMV - if your tools are primitive, maybe logging looks better...

This is why I call it the dev stream. I added a check for the content-type into my http library the other day - the idea being that if the content type was application/*, then it should default to utf-8. They key there is default - it should assume utf-8 only if nothing else was specified. However, that's not how I wrote the code... I was checking the content-type first, instead of at the end if the encoding had not been found. That was a dumb error, and made for a lot of bad text coming through. Fortunately, that only impacted the dev stream, and I've just fixed it - if you follow the dev stream, just grab the latest Http-Access and BottomFeeder components via the upgrade tool.

The New York Times has an article on outsourcing in today's edition. It's interesting because it takes a mostly negative view of the issue from a technology standpoint. However, most of the problems with outsourcing flow from a fairly old problem in software development - ironically enough, it's well stated in this defense of outsourcing:

In the future international division of labor, Mr. Pradhan said, the production of the technology will be done in places like India, which can deliver it reliably at a low cost. What cannot be sent to India, he said, is the invention of new business processes and technologies.

Conceiving inventory-management software that helps a retailer make the best use of electronic product tags, for example, might be something best done by system designers in the United States working closely with the retailer. Once such a system and its tasks have been mapped out, though, the software code could be written by programmers in India.

And boom, we've fallen into a management rahole and we can't get up. The rathole? Thinking that we can specify the software, throw the requirements over the wall, and then get something useful back later. This doesn't work well at all, and it doesn't matter whether the requirements are tossed over the wall to the local IT group or over the wall to Bangalore - the problem is the assumption that such a process can work. We have decades of experience with this kind of thinking, and anyone who's been paying the least bit of attention has noticed that it doesn't work well. I think I'll be wary of any project I hear of that comes from these guys - where Mr. Pradhan is a Senior VP. if they are promoting rocket scientists like that to senior VP slots, the very last thing they should be allowed near is important software systems...

That's hardly the only problem. Back in tech bubble of the late 90's, a lot of big companies brought in armies of consultants to help them build systems. The thinking seemed to be that the entire problem was that the consultants from (insert large consulting firm here) were too expensive. Guess what - that wasn't what the problem was. The problem was actually a lot simpler - these firms were farming out work to a horde of people they didn't know, but who were sold to them as experts. Did they understand the business domain? Typically not. Did they know the actual user base? Typically not. So now what are these same firms doing? Farming work out to a horde of people they don't know, but who are sold to them as (inexpensive) experts.

There's a saying that Insanity is doing the same thing over again, but expecting different results. Well, here are a bunch of large firms, doing exactly the same thing they did in the 90's - sure, it will cost less - but the results are looking to be about the same. It shouldn't be a surprise - the issues are all the same, only now there are additional issues of language and cultural barriers (not to mention time zone!) to boot. Expecting different results is just... stupid. Outsourcing software jobs is going to go about as well as hiring the expensive folks from (insert large consulting firm here) did. The only question is how the failures will get spun this time

There's an interesting Smalltalk debate referenced here - if you read Swedish. The summary is what I found interesting:

My column on the Smalltalk heritage on IDG has spawned a small debate about "industry languages" such as Java and C# compared to more dynamic, "cutting edge" languages like Smalltalk and Python. My take on the debate is that if you want to get stuff done togheter with other developers that may not be on the same level as you, C# and Java will get you there with the lowest amount of risk. For single-developer projects, or for small projects that everyone involved are really bright, Python and similarly dynamic languages (including Smalltalk, Lisp/Scheme, and even Perl) can get you there faster, while allowing you to have more fun along the way.

I know what he means about risk - but keep in mind that training developers in Smalltalk is fairly easy - it's not a complex language. I'd love to read this stuff, but Babelfish doesn't offer a "from Swedish" option....

remember this post from StS 2003? Well, the Ambrai guys just announced a public beta release:

Ambrai Smalltalk Beta Release
Ottawa, Canada - April 28, 2004

Ambrai Inc. is pleased to announce the beta release of Ambrai Smalltalk, a new Smalltalk development environment for Mac OS X.

Ambrai Smalltalk features a complete suite of native development tools that tightly integrate with the Mac OS Desktop. Currently these tools include package, class, category browsers, debugger, inspectors, and workspaces. Ambrai Smalltalk can be used to deploy Mac OS standard or console applications.

"We aim to deliver a rapid application development platform suitable to create new or script existing Mac OS applications. Whether you are a seasoned programmer or have never written a single line of Smalltalk code, we hope you will consider Ambrai Smalltalk for your next project." - Ambrai Smalltalk Development Team.

Founded in 2003, Ambrai Inc. is a privately held company based in Ottawa, Canada. Please visit http://www.ambrai.com to find more details and to download Ambrai Smalltalk.

One more reason to come to Smalltalk Solutions - you'll see the future before it arrives!

Smalltalk Solutions is rapidly approaching, and there's still time to register for the show! What will you miss if you don't come?

• Avi Bryant's keynote address on Seaside, and why it's a better way to build web apps
• George Bosworth's keynote address on the Microsoft CLR, and how it fits with dynamic languages
• Lars Bak's keynote address on Resilient, and why he chose Smalltalk instead of Java for embedded systems
• Smalltalk night at the Space Needle - have dinner with the Smalltalk crowd at the top of Seattle
• All the other fine talks and tutorials at this year's show

There's a lot of great stuff packed into three short days. See you there!

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...

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....

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.

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.

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.

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

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

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....

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 :)

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

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

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.

Scott Adams explains it all today. Heh.

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.

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...

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...

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.

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.

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.

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.

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

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.

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.

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.

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

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).

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...

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.

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.

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

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"

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.

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.  

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?

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

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.