 |
| From Boston '09 (Steven Noble) |
Seaside is a rare example of software that runs on all the major Smalltalk platforms: Pharo, Gemstone, GNU Smalltalk, Squeak, VA Smalltalk, and VisualWorks. We’ll take a look at some of the challenges in keeping the framework portable and some of the techniques the team has developed to deal with these. Along the way we may also touch on tools such as Grease, Slime, and Monticello and how they help the process. And then we’ll see where the discussion leads.
 |
Torsten posted a link to the announcement of GwtSmalltalk, which compiles to JavaScript and runs on top Google Web Toolkit and, thus, AppEngine. This is interesting coming only weeks after Avi's announcement of Clamato... there's clearly some interest around combining Smalltalk and JavaScript at the moment.
You can try out a demo. Hint, to create new instances you need to use:
Kernel instanceOf:
On a whim, while walking in London yesterday, I popped into the Tate Modern gallery. I'm not a huge modern art fan, but a few pieces caught my attention. Two of the most interesting were No Title (Table and Four Chairs) and Red Room, which I've just discovered are both by Robert Therrien.
Red Room is, as the title suggests, a room where every single object (except the single white light bulb in the ceiling) is practically the same shade of red. The room is packed with stuff and it's surprisingly compelling to look at. The collection of objects screams that there's some hidden story here waiting to be deciphered.
No Title (Table and Four Chairs) is a large scale (3.5 times normal) dining table and four chairs. On first glance, I thought, "ok, a big table". But the more I studied it, the more I was almost unable to walk out of the room. I began to contemplate the effect of looking up at the underside of a table, of standing barely higher than the seat of a chair. Obviously, as children, we all saw the world from exactly this position, but I found the situation almost impossible to fathom, let alone to recall. Very interesting.
Check out photos of both or if you're in London drop by the gallery and see them for yourself.
First of all, you are correct that you do not need to use a Component in order to access the Session. Seaside 2.9 moves
#sessionup to a new classWAObjectwhich makes it accessible to almost all Seaside objects (including Components) but you can definitely refer toWACurrentSessionyourself for now in 2.8.Components provide roughly the following functionality in 2.8:
#renderContentOn:is called with an instance of whatever renderer class you specify in#rendererClass(instead of whatever renderer is in use when your object is asked to render itself)- A hook (
#updateUrl:) to allow updating the URL used by the renderer to generate links- Hooks (
#updateRoot:,#style,#script) to allow updating the HEAD section of the HTML document- The ability to be the root of an Application
- Hooks (
#updateStates:,#states) to make state backtracking easier- A hook (
#initialRequest:) to allow initialization based on the request that caused the Session to be created- A facility (
#children) to make sure all components below you will also have the above hooks called on them- The ability to add Decorations
- The ability to show/answer/call (uses Decorations)
- Some convenience methods (
#inform:,#isolate:, etc)If you don't need any of the above, you don't need a Component. If you need any of the above, you pretty much do need a Component unless you want to implement the equivalent functionality on your own class.
The simplest metric is probably: if you intend to keep the object around between HTTP requests it should be a Component; if you intend to throw the object away and create it on each rendering pass it probably doesn't need to be. If you imagine an application that was displaying blog pages, you'd probably have Components for a menu, a blog roll, the blog body, each comment, and so on. You might want to factor out the reading of the blog's markup and generation of its HTML so that you could support different markups or different renderers and so that the comment Components could support the same markup. This could be done with a non-Component class that implements
#renderOn:and could be created and used by other Components as needed.Seaside 2.9 currently splits up the above functionality by making
WAPresenterconcrete and introducingWAPainteras its superclass. 1-3 above are implemented onWAPainterand 4-7 onWAPresenterso you have your choice of what to subclass depending on your needs. It also removes a lot of methods from WAPresenter and WAComponent in an effort to make them easier for end users to understand.
I've seen two references this week to Geoffrey Moore's Crossing the Chasm. I haven't read it yet but I've added it to my list.
Kent Beck describes the book's theory of market segments like this:
- Enthusiasts — will try new things for the sake of novely
- Innovators — will try new-ish things for the sake of business improvement in spite of some risks
- Early majority — will adopt proven products provided there is no perceived risk
- Late majority — will follow in adopting established products
- Laggards — the name says it all
He then goes on to highlight these observations of Moore's with regard to high-tech products:
- The gap between innovators and the early majority is particularly wide (the “chasm” of the book title), stymying many promising innovations
- Marketing is fundamentally word of mouth, but people in one segment don’t converse with people in other segments. This creates a chicken-and-egg problem in gaining traction in a segment.
- Messages that work for one segment don’t work for the next. The time to switch is when a product seems to be gaining momentum, because that segment will soon be exhausted.
Eric Sink adds:
One of the ideas in [the] book is that new innovations don't go mainstream until they become a "whole product".
Now Kent is talking about JUnit Max and Eric is talking about Distributed Version Control Systems (like git, Mercurial, and Bazaar) but this got me thinking again about Seaside's positioning and how to grow our user community. I think GLASS, by providing integrated persistence, is a big positive step towards making Seaside seem like a "whole product". But what else is missing? Deployment/admin tools and documentation spring to my mind and I'm hoping to make a start on the latter with some of the posts on this blog. But what else?
Growing support by major Smalltalk vendors helps reduce the apparent risk within a small segment of the market but, for many people, Smalltalk itself is seen as a major risk. So part of making Seaside less appealing would involve either de-emphasizing its use of Smalltalk (not really going to work—people will notice eventually) or reducing the apparent risk of Smalltalk itself. That's no small task and the vendors, I'm certain, have this at the front of their minds. Still if anyone has any thoughts on how Seaside in particular can contribute to that effort, I would love to hear them.
One of the major perceived risks associated with Smalltalk, of course, is the relatively small number of developers using it. Thus we have a feedback loop there: more users means less risk, which means more users, and so on.
So three important questions, I think, are:
No answers yet; just questions. If you have any thoughts, please share.
It kind of surprised me that it was true, though: I used to be an obsessive preference tweaker but that animal urge seems to have died out along with the desire to immerse myself in video games until 5:00am. I still troll the preference dialogs of any new application, looking for options with as much clout as the Turbo button on old 386 machines, but I can usually close these dialogs without saving."But wait!" you say. "It's important to have options for advanced users who want to tweak their environments!" In reality, it's not as important as you think. ... Most advanced users use several computers regularly; they upgrade their computer every couple of years, they reinstall their operating system every three weeks. It's true that the first time they realized you could completely remap the keyboard in Word, they changed everything around to be more to their liking, but as soon as they upgraded to Windows 95 those settings got lost, and they weren't the same at work, and eventually they just stopped reconfiguring things. I've asked a lot of my "power user" friends about this; hardly any of them do any customization other than the bare minimum necessary to make their system behave reasonably.
I found myself in a bookstore the other day and the limited selection of English books made it seem like time to check out The Long Tail (note the link is not to the same edition that I read).
The thesis is interesting: that consumer behaviour is changing due to increased selection, decreased distribution costs, better filtering and recommendation tools, and expanding access by amateurs to creative tools. The idea is that selling a few each of a million different things can now constitute a sizable and legitimate market. The history of mail order and consumerism in the United States also held my attention and there were pearls of interesting information about particular industries and companies thrown in.
Those were the good parts. But man do you have to wade through an enormous heaping pile of repetition to find them! I mean, I complained about the repetitiveness of Don't Think of an Elephant but The Long Tail makes that slender tome look like a particularly succinct haiku.
Anyone near me while I was reading will be able to confirm my level of frustration: every chapter or so I would snap, get up, and complain to whoever was nearest at the time (sorry!). Right down to the last chapter, we were still being treated—in every subsection!—to a paragraph-long definition of "long-tail economics" and its effects on commerce and consumers. Yes! Ok! We get it already!! The book should ha... I said we GET IT!!! The book should have been called The Long Read[1].
Basically The Long Tail should have just been an essay. In fact, it was just an essay so I wouldn't waste your money on the book. And if the original essay leaves you wanting, you can always try Wikipedia.
Don't Think of an Elephant also came out of a collection of essays so maybe this is a lesson for me (though it ought to be a lesson for authors). I bought Freakonomics at the same time as The Long Tail and I see it is also a collection of essays; so that doesn't thrill me with enthusiasm. Can anyone give me any comfort on that one? At this point even boring would be ok as long as it isn't repetitive...
[1] Credit for the title goes to Andy Stote. ;)
This is the next in a series of posts looking at changes in the upcoming Seaside release. Check out the other posts on partial continuations and exception handling.
The upcoming release of Seaside will feature some changes to the now-familiar WAKom. The existence of various subclasses like WAKomEncoded and WAKomEncoded39 was beginning to point at a usability problem and we wanted to facilitate running Seaside on multiple ports out of the same image.
First of all, we have introduced an abstract class, WAServerAdaptor. Server Adaptors provide an interface between Seaside and a particular server or connector (e.g. Comanche, Swazoo, AJP) and are able to start and stop server instances on the correct ports. Most importantly, they are also responsible for translating between Seaside's WAResponse and WARequest objects and the native requests and responses required by each server.
Server Adaptors are configured with a port number and a Request Handler. They are also configured with a Codec, which specifies the character conversion that should be performed when converting the requests and responses. Character encoding issues are complex, however, and we are still playing with those interfaces so I will leave that discussion for another time. Server Adaptors get registered with an instance of WAServerManager (currently a singleton) when they are created and the Server Manager coordinates starting and stopping the servers.
To create and start a new Comanche adaptor, you could simply execute:
adaptor := WAComancheAdaptor port: 8080.
adaptor start.
Alternatively, you can use the new Control Panel (implemented with OmniBrowser) to create and configure your adaptors. You can now create and run multiple adaptors of the same type. You can even configure multiple adaptors on the same port (perhaps to facilitate testing different servers or codecs) though only one can actually be running at any time.
Note that WAKom and its subclasses still exist for backwards compatibility in this release and will start an appropriately-configured instance of WAComancheAdaptor. These classes, however, only support running a single adaptor instance at a time and will be removed in a later release. Once created with WAKom, the adaptor will be visible in the Control Panel and can be manipulated there just like any other adaptor.
I mentioned that Server Adaptors can also be configured with a Request Handler. Why would you want to do that? By default, all Server Adaptors dispatch incoming requests to the same default Dispatcher. But perhaps you have an admin interface that you want to run on a different port so it can be firewalled to an internal network. Perhaps you want to make Seaside's web config tool available through an SSH tunnel. Or perhaps you have an XML-RPC interface or a status page for integration with a service monitoring tool. Maybe you just want to transition your application behind a load balancer to a new instance with different configuration options. Whatever the case, if you just want to configure a new Dispatcher using the web interface, the Control Panel has a context menu option called "Use new dispatcher" which will give you a new blank starting point on that Server Adaptor. If you have an existing Request Handler somewhere you can tell the Server Adaptor to use it like this:
adaptor requestHandler: myRequestHandler
Using a Dispatcher at the root will allow you to configure multiple Request Handlers at different subpaths but you could just as easily use an instance of WAApplication, RRRSSHandler, or any custom Request Handler subclass (more on this in a future post) if you want all requests to be handled in one place.
First of all, I apologize for the title: I was exposed to this name—so awful it's almost good—for our current decade only last week and felt compelled to throw it in. And yes, I realize I'm a bit late coming to this party.
Paul Graham's latest post talks about the challenges of maintaining the culture of his Hacker News site [link withheld to protect the innocent - you should be able to find it]. What I found interesting, though, was this almost offhand comment right at the end:
I feel like the addictiveness of games and social applications is still a mostly unsolved problem. The situation now is like it was with crack in the 1980s: we've invented terribly addictive new things, and we haven't yet evolved ways to protect ourselves from them. We will eventually, and that's one of the problems I hope to focus on next.A way to protect ourselves from the crack that is the internet... Wikipedia safe injection sites? What do you have in mind, Paul?
This is the second post in a series looking at the upcoming new release of Seaside. Check out the first post on exception handling.
Seaside is often referred to as a "continuation-based" web framework and certainly in its early days continuations were used throughout to work its magic. Seaside 2.8 still uses first-class continuations (more on what that means in a minute) in three different places:
The next upcoming release of Seaside, however, will completely eliminate the use of continuations within the core framework itself. Case 1 has been reimplemented using exceptions and the code for 2 and 3 moved to an optionally-loadable package. This means that you can now choose to install Seaside without using any continuations at all, which is good news for portability to a few Smalltalk dialects that don't currently support continuations.
At the same time, we are also replacing our use of full continuations with partial continuations and this article will look at what that means and why we are making this change. This stuff can get confusing (particularly while debugging it!) so don't worry if you have to let the information mellow and then come back and read it again. I've simplified a few things, sacrificing detail in the hopes of making the subject more comprehensible for people who are just curious about how it works. I'd appreciate any feedback on how well I've struck this balance.
First of all, when I talk about continuations here, I'm talking about first-class continuations. Seaside also uses a continuation-passing style to implement its application render loop (this is the _k you see in Seaside URLs). This is a somewhat-related concept but is not what we're talking about today.
Continuations are often defined as "the remaining computation" but I think this can seem a bit obscure if you don't already understand them. To me, the simplest explanation is that a continuation saves a snapshot of a running process that you can resume later. You call a method, which calls another method, which calls another method, and so on and then at some point you create a snapshot of this chain of methods and save that snapshot object somewhere. At any point in the future you can restore it, abandoning the code you are currently running, and your program will be back in exactly the same place in exactly the same method as when you took the snapshot. That's a first-class continuation.
Smalltalk users should not find this too hard to come to terms with. When you save your Smalltalk image, you can open it later and be back exactly where you left off. You can open that saved image as many times as you like and return each time to the same state. If you save the image into a new file, you can still go back and load the old image. A continuation does basically the same thing but captures, instead of the whole image, only a single process.
One of Seaside's most-demonstrated features is the ability to write multi-step tasks that query the user for information:
answer := self confirm: 'Do it?'.
answer ifTrue: [ self doItAlready ]
This is exactly the kind of thing we facilitate with continuations: we need to pause in the middle of this method to ask the user for feedback. If they ever answer the question, we want to resume the method where we left off. So let's look at how first-class continuations might be used to make this work.
But first a word of explanation. The following diagrams depict context chains (though they are abstract enough that they could just as easily be a stack of frames). Every time you call a method or evaluate a block, a new context is created at the "top" of the chain. Every time a method returns or a block finishes, the topmost context is removed. The method context knows what method is being called, what object it was called on, and the value of any variables defined in the method. It also knows the context below it in the chain. If you need help understanding this process, take a look at this example illustration which shows the process step by step.
The diagrams below each represent a chain of contexts handling a single HTTP request. Each request is the result of clicking on a link and each causes the execution of a callback. Each callback eventually sends either #call: or #answer:.
The diagrams show the context chain at the point in time when #call: or #answer: is sent and then try to illustrate what happens next. The upward-pointing arrows show the progress as methods are called and the downward-pointing arrows show the progress as methods return. I show exceptions with a dashed arrow, the tail coming from the location where the exception is raised and the head pointing to the location where it is handled. In cases where a continuation has been saved, the diagrams show both the currently executing context chain and the saved one and the arrows behave as normal. Obviously these are very simplified illustrations; I'm more interested in getting the general idea across here than in the exact details.
To help make things clearer, each diagram is marked with a gray line. Everything above the gray line is user code: part of the callback that is being executed. Everything below the gray line, is part of the internal framework code: reading from sockets, looking up sessions, and so on.
Ok, so let's look at one possible implementation using continuations. Let's assume a user is staring at a web page with a link that says "do it". Clicking on that link will execute a callback with the example code shown above, which should prompt the user with the question "Do it?". While processing this request, the following things happen:
The response to the browser should show the prompt "Do it?" and a link or button to confirm the action. When the user confirms the action, they trigger another callback, which will execute self answer: true. When this second request is received, the following happens:
The problem here, and why I called this a naïve implementation, is that you can see the response is incorrectly returned to Request 1. The socket associated with Request 1 is, unfortunately, long gone and the browser is no longer waiting for a response over there. The browser is, in fact, waiting for a response that never arrives on the socket associated with Request 2. Ooops!
So the first implementation doesn't work but hopefully you can see what was going on with the continuations. The problem is that, when we restore the continuation, we really don't want to abandon everything the framework is doing. At the very least, we need to keep the contexts that will return the response to the correct socket.
A simple way to limit the contexts captured by a continuation is to create a new process. A new process starts with a new, empty context chain, so when we create a continuation only the contexts in that chain will be captured. We can use a semaphore to cause the first process to wait while the new process handles the request. When the second process is finished, it signals the semaphore and the original process returns the response to the correct place.
This diagram shows exactly this (the contexts of the two processes are shown with different symbols):
So far, the only benefit here is that the continuation is smaller. But when the second request comes in, you'll see how this starts to solve our problem:
So not only is our continuation smaller, but the second response actually makes it back to the right place. This, by the way, is the implementation used by Seaside 2.8 and earlier versions.
There are a few significant problems with this approach though:
Enter partial continuations. A partial continuation simply means that, instead of saving the entire context chain, we save only the part we are interested in. And when we restore the partial continuation, we don't replace the existing context chain entirely; we only replace the part that we are not interested in. Let's see how they work.
When the first request comes in, things work much the same as in our very first example so I won't number the steps. In fact, things work exactly the same except for one thing: using partial continuations, we can now specify the exact range of contexts to save in the continuation. In this case, we choose to save only the contexts that are part of the user (or callback) code. Remember the problems from the first implementation? The framework code is handling one particular HTTP request; these framework contexts would be completely useless to us when responding to any future request (and another request for the same URL is still a new request). Since a callback can span multiple HTTP requests, it is only those contexts that make up the callback that need to be saved and resumed later.
Remember also that the context chain is, in reality, much longer than shown in these diagrams: we might be storing five contexts now instead of, say, 40! A nice space savings.
Now let's look at the second request coming in. This illustration is a bit different and a little more complex because the context chain actually changes during execution, so I will explain it step by step:
Magic! It sure feels like it and it works beautifully. We have tiny saved continuations, we don't need a new process, and all our framework contexts get a chance to complete.
The partial continuation solution is currently implemented in the development version of Seaside and will be in the next release. Squeak and VisualWorks already support the implementation of partial continuations in Smalltalk code. GemStone is nearly finished adding support to their VM. Smalltalk implementations that cannot easily implement partial continuations have three choices:
By the way, at the same time as I was working my way through those subtle bugs I mentioned earlier, Eliot posted about stacks and contexts in the new Cog VM he's working on. As well as being very interesting reading, it shed some timely light on the meaning of primitive 198, which pointed me in the right direction and probably saved me an hour or two. Thanks Eliot! Check it out if you have the time.
I hope this was useful or interesting reading and would love your feedback on anything you found challenging or helpful to your understanding. Happy Seasiding.
Contrast that to (relatively small-town) Germany: here I'm not given the role of "foreigner". Here I look pretty much like everyone else so, instead of being a convincing expat, I sometimes feel like an unconvincing German. 
This reminded me of a blog post by Jeff Atwood from a while back about the Uncanny Valley hypothesis. This hypothesis relates to all kinds of things from robotics to animation and (Bill Higgins says) web-based user interfaces. The idea is that, as one thing gets closer to mimicking something else, the remaining differences make us feel increasingly uncomfortable. So, for example, an animated character (like the one above, from Polar Express) that is trying to look human may feel creepy but one that looks nothing like a real human (Homer Simpson, for example) may feel totally natural. By the way, if you haven't seen it, check out how far computer generated animation and motion capture can currently take us: meet Emily.
