A Brief and Highly Inaccurate History of Wasabi

Wasabi, like all things, is a product of its history. FogBugz started life as a Classic ASP application as on Windows, at the time, it was pretty much the only technology for building web applications. At some point later, somebody decided that they wanted to run FogBugz on Linux. Unfortunately, FogBugz on Demand didn’t exist yet and while products existed that ran ASP on Linux they cost more than FogBugz did. Noticing the similarity in semantics between ASP and PHP an idea was born: Thistle.

Thistle was origionally an intern project to produce a source-to-source translator that translated ASP into PHP by adding dollar signs to variable names and implementing LBound and UBound in PHP. This allowed something magical to happen: FogBugz could run on Linux. It didn’t necessarily run particularly well and the Linux release of FogBugz would often lag weeks or months after the Windows release shipped as we got the PHP version working, but the fact remains that we had a Classic ASP application running on Linux and we didn’t have to pay anybody for the privilege.

The “lagging weeks or months...” thing resulted in another idea: Add an ASP backend to Thistle and run that instead of the hand-written ASP. This would allow us to make sure that Thistle was generating sensible code during development as opposed to during the mad dash to get PHP FogBugz working. This idea opened the door to another idea: Since we’re generating both the ASP and PHP that actually runs, we’re no longer restricted to VBScript+Tie-Fighters as our input language. We could add features, so we did. We added type-inference and Lambda, and For Each and Do While and <ExecuteAnywhere> and <ExecuteAtCompiler> and various and sundry other features until FogBugz was no longer a Classic ASP application and the language it was written in could no longer be properly described as VBScript. Thus, Wasabi was born.

ASP.NET was released in 2002, and this was the beginning of the end for Classic ASP. Unfortunately, the extensions added by Wasabi and the desire to run on Linux meant that there wasn’t any straight-forward migration path from ASP to ASP.NET, which meant that FogBugz ended up using the Classic ASP runtime until well past it’s sell-by date... and the ASP runtime did not age well: It was pretty much the slowest runtime in existence and while the PHP backend had improved it was still a bit of a mess. Consequently, after FogBugz 6.0 shipped we decided that we really needed to target a different runtime and selected .NET. .NET had the advantages that it worked really well on Windows (which is our platform of choice thanks to our Classic ASP heritage), ran a <bizarre metaphor> faster than Classic ASP, and due to the emergence of Mono it was possible to run .NET applications on Linux without the need for the PHP backend.

While the .NET version of FogBugz was initially going to be shipped as FogBugz 6.5, we decided that a new release without features wasn’t worth it. Taking advantage of Wasabi’s new found .NET features, we created a plug-in API and several plug-ins to address a number of frequent but minor customer issues. Those plug-ins plus the new .NET architecture we released as FogBugz 7.0. As part of the 8.0 release cycle, we implemented several large features as plug-ins, notably Reporting, Mobile FogBugz and some wiki enhancements which has cemented FogBugz as a .NET application.

This Book

On of the biggest issues of with Wasabi is that it is completely undocumented. Given Wasabi’s VBScript heritage, it’s obvious C# influence and it’s kitchen sink approach to features, the lack of documentation means that it can be genuinely frustrating to figure out how to do even the most basic things. This book is an attempt to document what I know about Wasabi so that I never again have to rediscover how to do constructor chaining or try to figure out whether or not Wasabi has a continue statement (it doesn’t).

I am writing this using Sphinx as a form of cargo cult documentation. Basically, I know of several well documented projects that use Sphinx (Python, Django, Paver) and basically none that use Javadoc style automatic documentation (the Java standard library’s Javadocs being shining example of how to do it right and pretty much everything else I’ve seen (including MSDN) being an example of how to do it wrong). So I’m using Sphinx in the hope that I’ll some how end up with reasonable documentation.

If you would like to share what you know about Wasabi, patches are welcome ;-).

Table Of Contents

Previous topic

Wasabi: The ??? Parts

Next topic

A First Program

This Page