Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
A Look at the Buzzword Spell Checker Implementation
Posted by Jon Rose on Dec 11, 2007
Buzzword’s core spell checking engine is Grant Skinner’s Spelling Plus Library (SPL). SPL is a commercial licensed product written 100% in ActionScript 3 – the programming language for Flash / Flex.
Coletta discusses this in his blog post on the September release:
We hooked up Grant Skinner’s excellent Spelling Plus Library (SPL) to our editor to provide dictionary lookup and suggestions. SPL is implemented entirely in ActionScript 3 and is very small and fast, plus it provides the ability to download and decompress the dictionary in the background while the application is starting up, so the user doesn’t have to wait while the dictionary is loading. In addition to SPL’s high level interface for easily including spell checking into Flex and Flash components, there’s a low-level API for doing word lookup and suggestions (which is what we are using). It’s great to have a spell checking solution implemented entirely on the client side, so that, down the road, it’ll work just as well when we support disconnected use.In Coletta’s post this week, he discusses some of the challenges with the singled threaded nature of the Flash runtime:
Buzzword needs to do as little work as possible on each keystroke, to keep the user interface responsive, but we don’t have the luxury of using a background thread, because Flash provides only one thread on which ActionScript can execute. (There are ways to do background processing using timer and frameEnter events, but you have to carefully manage contention between those event handlers and the “main thread” yourself.) In Buzzword, we do all the spell checking work synchronously. We considered doing it in the background, keeping a list of dirty regions of the document, and working through the dirty list on timer events while the user is idle, but it would have added a great deal of complexity and indeterminacy to the design, so we decided to try to do it all in the foreground and see how well it worked. It turned out to be an adequate approach.Along with the challenges of implementing the spell checker in a single threaded environment, Coletta discusses the performance challenges:
One of the things we do to make sure that Buzzword starts up as quickly as possible is to load and decompress the main spell check dictionary in the background. (Actually, the background loading and decompressing happens inside the SPL library, so any user of that product gets the benefit.) However, loading the dictionary in the background has a downside: it creates a race condition between the loading of the dictionary and the editing of a document. It’s not hard for an agile user to do about five or ten seconds of work on a document before the dictionary is fully available to be used for spell checking. Making the user wait five or ten seconds would be bad. Normally we only recheck the flagged words when the document opens, but in this particular case, since the user was allowed to edit for a while without any “as you type” checking, we have to rescan the whole document as soon as the dictionary loads.Read on at David Coletta’s blog posting, as he discusses some of the challenges of adding the spell checker feature while supporting the collaborative nature of Buzzword. There are clearly new considerations with building RIA applications like Buzzword, when compared with more traditional server-side frameworks. For Flex applications, the new challenges are often related to the new use cases that come with the power of the platform – along with the nuances of client-side programming for the Flash Runtime.
No comments
Watch Thread Reply