June 2013

Glass Ceiling

Glass Ceiling is the ultimate female revenge fantasy. In Glass Ceiling, our hero Moxie fights her way up the corporate ladder—literally. By battling fresh men, backstabbing co-workers, asinine accountants, bad bosses and other office stereotypes.

Graphic and game design by Wendy Carmical, project management and game design by Maura Sparks.

It's written in C++ using OpenGL, and thus is completely portable between iOS, Android and OSX.

February 2012

Cartesian

Representations of rectangles and points are essential in any system working with graphics. Every API and many applications define their own. Depending on the era of the API there may be a full suite of algebraic-style operations, or the types may be simple data carriers with a handful of manipulating functions provided.

So what happens when bodies of code collide? Well, we end up with ad hoc transference of information from one representation to another, and chunks of code using a rich representation just look different from chunks using something more primitive.

In ZooLib I made several attempts at creating a clean suite of cartesian types and operations, with conversion operators and constructors, pseudo constructors and miscellaneous helper functions. But the approach just never scaled well.

Recently I've taken a very different tack. In ZCartesian I've defined a suite of template accessor functions -- passed a rectangle/point the edges, corners and centers can be extracted. Offsetting and aligning operations build on those accessors, as do sensible algebraic operators.

The accessor functions themselves forward to functions defined in traits templates. There's a suite of base classes for rectangles that are defined by variations of origin/extent or left/top/right/bottom. Supporting a new suite of cartesian types can be as simple as providing the definition of a traits class inheriting from one of the provided bases.

In this way we can work with NSRect, CGRect, XRectangle, QuickDraw Rect, Windows Rect, SDL_Rect, and their associated point (and size) structures using identical notation. And when we need to switch representations there's just a single pseudo-constructor to do the job.

July 2010

Callable

A couple of projects required that I get fairly serious about working with Javascript. And like so many I found a nice little language muddied by the vagaries of DOM implementations and some unfortunate syntax edge cases. The flexibility of having functions as a first class entity was something I'd been aware of in the abstract, but working in Javascript really drove it home. About the same time I had to do real work with Objective-C and Cocoa, both on Mac and iPhone.
The compositional flexibility of Javascript and Cocoa was liberating and disconcerting. After all there's real utility in the rigidity of C++'s type system; the compiler becomes an ally in the exploration and definition of a problem's characteristics. But those Javascript and Objective-C callbacks are themselves compelling.
My response to that tension is ZCallable. Certainly not the first generic callback mechanism, but one I've found comprehensible and usable. The basic template suite: ZCallable_Block, ZCallable_Function, ZCallable_ObjC and ZCallable_PMF encapsulate the several forms of function in C++ and Objective-C++. ZCallable_Bind provides closure-like facilties, and other parts of the suite provide mechanisms for combining and parameterizing callables.

June 2010

Natter

Multiplexing comms over a single bidirectional channel is a useful ability. ZStreamMUX has proven itself, but to support fully bidirectional substreams it uses a pair of threads for each MUX instance, and another thread for each pending listener. For RPC-ish situations this is overkill.
Natter is a lovely English word that well describes a lightweight back and forth between participants. A ZNatter is constructed with a ZStreamerR and a ZStreamerW instance (often two aspects of a ZStreamerRWCon instance).
From instantiation the two sides of a ZNatter are symmetrical, each sending and blocking till a response is received. Of course the interesting situations are the beginning and the end of such an exchange. On the server-ish side we call ZNatter::Receive. The result of such a call is a ZQ<ZData_Any>, with a ZRef<ZNatter::Exhange> as an optional output. On the client-ish side we can call ZNatter::Send and disregard any response, or we can instantiate a ZRef<ZNatter::Exchange> passing the ZNatter with which we wish to participate, and then call its SendReceive method.
It's certainly a constrained communication mechanism, but one that maps cleanly to common patterns with no extraneous resource implications.

April 2009

YadTranscode

YadTranscode is a useful little command line tool. There's a bunch of data formats out there that might look different at first glance but on reflection can be seen to be isomorphic.

Most computer languages provide a suite of atomic data types, values that are generally not themselves subdivided. These usually include numbers, booleans and strings, may also include raw binary, and may make distinctions amongst various sizes of floating point and integer numbers.
Languages generally include an aggregate type that is called an array, vector or list, being a sequence of values. Languages also usually include a hash, dictionary or map type that is a collection of name/value pairs indexable by name.
Persistent data structures and streamed protocols very often reflect these divisions -- a larger or smaller suite of atomic types plus the two aggregates. If you squint you can see the commonalities amongst the QuickTime/MPEG4, bencode, plist and json formats. Various flavors of XML-based serialization fit the pattern, and even the venerable CSV can be treated as a sequence of maps of atoms.
YadTranscode reads sources of several formats: bencode, json, quicktime, tab/CR tables, xml plists, a couple of stylized xml formats and a custom binary format. It transcodes that data and emits json, xmlplist, a type-rich text format akin to Next-style plists and a custom binary format.
It's built on some of the wide suite of ZYadR entities in ZooLib.

March 2009

ZooLib BBDaemon

The ZooLib BBDaemon lets multiple Mac applications talk to USB-connected BlackBerrys concurrently. Obviously this is something that Research in Motion could make possible, but as they haven't we're posting a pre-built installer that takes the pain out of getting things working.

If you're using Missing Sync for BlackBerry 2.0.1 and iMobimac Modem then this is what you need.

BBDaemon runs as a user-space process, not a kernel extension. The installer simply puts the executable in /Library/PrivilegedHelperTools and a launchd control file in /Library/LaunchDaemons.

RIM's own Mac applications (PocketMac for BlackBerry and BlackBerry Media Sync) take a different approach. They each install a kernel extension which grabs any USB-connected BlackBerry, and prevent any other application (including each other) from being able to talk to it.

The installer we've posted was built with revision 533 of ZooLib. You can check out the source and build it yourself:

svn export -r 533 https://zoolib.svn.sourceforge.net/svnroot/zoolib/trunk/zoolib

svn export -r 533 https://zoolib.svn.sourceforge.net/svnroot/zoolib/trunk/zoolib_samples

cd zoolib_samples/BlackBerry/BBDaemon/osxpackage

sh build.sh

The executable and launchd file must be owned by root/wheel, so the build.sh script uses sudo to change the ownership – thus you must be logged in with an administrator account and you may be prompted to enter your password.

March 2008

Mac/BlackBerry SDK

The BlackBerry is a very popular mobile communications device. Official Mac support from Research in Motion is limited to providing the PocketMac utility as a free download. With no official SDK the Mac/BlackBerry ecosystem has seen very little activity.

ZBlackBerry is a suite of code that implements the BlackBerry USB communications protocol in a generic fashion. A few hundred lines of code let Macs use that protocol. A few hundred more allow multiple Mac applications to talk to a single BlackBerry simultaneously, something that has not been possible till now.

ZBlackBerry can also make a BlackBerry connected to a PC accessible via the same API as is used when it's connected directly to a Mac. This lets Mac application developers run their BlackBerry application under the Windows-based debugger and still have it communicate with their Mac application. This is a crucial capability when writing anything more than the most trivial application.

ZBlackBerry is part of ZooLib, our open source C++ library.

January 2006

WebDAV

WebDAV is an extension to the HTTP protocol. It is the basis for Apple's iDisk and Windows' Web Folders, standard features of Mac OS X and Windows XP. It is thus the easiest way for a server to make data available to a client machine without requiring that client software be installed first.

ZooLib provides a generic WebDAV server. Your application need only implement subclasses of ZNodeRep to represent nodes in your desired hierarchy. Standard subclasses of ZNodeRep let you lay one tree over another, or expose part of the server's file system to clients.

Frankly, WebDAV is an inelegant protocol. It puts some information in the URL, some in header lines, and some is encoded as XML in the body of requests and responses. But it has three sterling characteristics:

  • It exists
  • It works
  • It's usable out of the box on Mac, Windows and many flavors of UNIX

December 2005

Windows Services

UNIX does not make an explicit distinction between programs that are servers vs programs invoked by a user. Each flavor of UNIX provides a mechanism for the management of these programs, generally by using naming and placement conventions of descriptor files in the file-system.

In contrast, Windows NT/XP supports servers with a specialized API and management tools. Windows services are packaged as regular applications, but when they are invoked by the service framework they register a callback with that framework to which status and control messages can be delivered.

Turning an application into a service is straightforward, but involves a certain amount of boiler-plate code, and requires that the application be structured to be controllable by a thread started by the Service framework. The ZooLib class ZWinService implements the boiler-plate, and at its simplest requires only that a Run and Stop method be implemented on a derivation of ZWinService in order to connect an application to the service framework.

May 2005

ZTSoup: UI-Friendly Tuplebase Access

The tuplebase API is well-suited to data processing needs. But it's clumsy as the mechanism by which data in a tuplebase is to be presented and maintained in a live UI, rather than web pages or generated reports.

ZTSoup gets its name and inspiration from the Apple Newton concept. A ZTSoup is backed by the same data as a tuplebase, but that data is accessed by instantiating a ZTCrouton for each tuple that code is interested in, and a ZTSieve for the result set of any query of interest. Why the funny names? A soup has croutons floating in it, interesting ones are sieved out of it.

There are two problems with connecting a UI to a transaction-based store like the tuplebase. First, how do you efficiently identify the minimal set of interesting changes that have been made in the tuplebase. Second, in reading or writing data, what do you do when a transaction fails to commit?

ZTSoup addresses these problems by maintaining objects locally that record a snapshot of the subset of the tuplebase in which the software is interested. Local changes are recorded in those objects, and they are sent to the tuplebase as a single atomic update operation. It's simply a matter of hooking a call to the soup's Update method into the normal event loop -- all additions and removals of interest in croutons and sieves are sent to the tuplebase, and remote changes to the croutons and sieves are returned.

Because the soup may be talking to a tuplebase on the end of a comms link the update work is split into a synchronous piece, which executes in a small amount of time with no blocking, and an async piece that accumulates work done by the synchronous piece and communicates with the server as fast as latency and server CPU will allow.

May 2004

Java Tuplebase Access

Initially I provided Java access to a tuplebase instance by implementing Java classes whose most interesting methods were marked as native, and thus invoked via JNI. This was very powerful because Java could use any tuplebase implementation simply by calling the appropriate factory function and I could expose any existing C++ functionality simply by implementing the appropriate JNI glue.

But native code can't be included with unsigned applets, so I ported ZTBRep_Client from C++ to Java. ZTBRep_Client is the most useful tuplebase implementation in that it talks to a ZTBServer instance on the end of a comms link, generally a network socket. It's also fairly large, and the async nature of the protocol makes things somewhat tricky. The normal Java synchronization model is based around monitors, which are not directly useful for implementing certain types of concurrent processing, so I implemented condition vars and mutexes to provide more appropriate tools.

May 2003

ZDCPixmapBlit

ZDCPixmapBlit uses templates to generate the code for source/destination and source/matte/destination blitting, matte/destination filling, and destination-only munging, using the four Porter/Duff composition operators Copy, Over, In and Plus.

November 2002

Electric Fence and Threads

Electric Fence is an immensely useful library written by Bruce Perens. It uses the standard UNIX memory mapping API to put guard pages on either side of memory allocations, thus causing a segment violation as soon as your code writes where it shouldn't. I made a few small changes to make it possible to use from a preemptively multi-threaded application.

November 2002

Web Browser Plugins

ZooLib's UI code requires only that there be a ZFakeWindow-derivative at the top of the enclosure hierarchy. In the distant past ZooLib included implementations of ZFakeWindow for Mac control panel cdevs, HyperCard XCMD windows, MacroMind Director XObject windows, Zoom closures, MacApp views and of course still does for ZOSWindows.

It was thus relatively straightforward to implement ZFakeWindow_NSPlugin, which translates between the Netscape browser plugin and the ZFakeWindow APIs. What was actually more difficult was finding a decent implementation of the plugin glue code and header files. In 2002 there wasn't anything that would work with current compilers and with current browsers, so most of the effort was in putting together ZNSPlugin, which is a usable implementation of the glue.

October 2002

Tuplebase

ZooLib's tuplebase is derived from the tuplespace concept initially explored in the Linda coordination language, another well known derivation of which is Sun's JavaSpaces system. Whereas JavaSpaces is Java-only and relies on many of that languages's features, ZooLib's tuplebase works today with C++ and Java, and is well suited to work with other languages.

Language agnosticism is a key feature of tuplebase. Another is its runtime flexibility, which contrasts with most relational database implementations.

The power of a relational database is that the data it stores conforms to a rigorously defined structure. For a single piece of software it's always possible to find a single structure that supports all the work to be performed. As the nature of that work changes the database schema is evolved along with it. But this evolution must be coordinated so that all software that depends on the schema is updated to accommodate the changes, or virtual views are created to preserve a logical interface to the data.

Tuplebase takes a very different approach. Rather than enforcing a structure it allows any structure at all to be stored. Different pieces of software with overlapping concerns obviously must coordinate amongst themselves, but there's no requirement that there be any single authority managing everything. And because there's no mandated structure it's possible at runtime to treat multiple physical tuplebases as a single logical tuplebase, even if they contain data of different provenances. If the code using the data is written to be accommodating to the gradual migration of meaning then newer code can correctly interpret older data, and older code will ignore (but preserve) newer data.

October 2002

ZDC_ZooLib: Portable Graphics

ZooLib defines and implements a graphics API that produces identical results across all supported platforms. It is geared towards creating user interface elements and so is pixel-based rather than geometric so that a programmer can know precisely which pixels will be touched by a drawing operation. It supports pixel-plotting, lines of any thickness, text, rectangles, rounded rectangles, ovals, arbitrary regions and the drawing of masked-pixmaps. ZDC_ZooLib is an implementation of this API using no OS facilities at all, and thus can be used in server applications without the difficulties that normally poses (gaining access to a window or graphics server from a low-privilege process).

The implementation uses operations on ZBigRegion instances to decide which pixels to touch, decomposes the regions into rectangles and then calls ZDCPixmapBlit to actually do the work.

IFF and QuickTime File Formats

IFF is a venerable data meta-format, introduced in 1985 by Electronic Arts as a standard framing mechanism for multimedia data. In short it defines a nested chunked format, where the file as a whole is considered to be a chunk. A chunk has as its first four bytes a tag that indicates the type of data in the payload, a 32 bit (four bytes again) count of the number of bytes in the payload, and then that number bytes being the payload itself. Some chunk types are known to contain zero or more other chunks in their payload, so an arbitrarily complex hiearchy can be established. There are other details, but chunk types and sizes are IFF's essentials. QuickTime's file format is almost the same, except that the size comes first, and includes the eight bytes of the chunk header.

IFF/QT are simpler than most file formats, but can still be fiddly to work with. To make it easier for me to parse and generate QT files manually (on platforms which don't have QT libraries) I put together a suite of ZooLib streams that take care of all the bookkeeping.

Tuples Defined Rigorously

For most of my career I've been very suspicious of dynamic data representations. After all, what's the point of having a compiler if it isn't provided with enough information about the shape of the data being manipulated to tell you when your code is going wrong. However, that really only works for data created and consumed within a single application. In the mid-90s, every C++ framework worth its salt had a huge bunch of code dedicated to turning arbitrary C++ objects into something that could be serialized and regenerated as objects later; and in fact that's about as far as most people got with CORBA before giving up.

But most objects in a C++ program, if they're objects at all, simply don't need to be serialized. The ones that do have disparate needs, and special cases abound. The approach I've found most flexible and least intrusive is to provide ZTuple. In this context a tuple is isomorphic to a LISP a-list, Python or Cocoa dictionary, Perl or Ruby Hash or to a Java Map. It's simply a list of name/value pairs, where values can be primitives (strings, numbers, raw bytes etc), tuples or lists of values.

ZooLib provides a suite of facilities that read and write tuples to binary streams, generate and parse a well-defined and easy to read text format, and that can read and write appropriate data formats as tuples.

April 2002

Files

Most of my work till this point had not required 'interesting' operations with file systems, being restricted to creating and opening files in externally determined locations, then reading and writing the files' contents. When it became necessary to ennumerate the contents of directories, and to deal with permissions and locking I took the opportunity to define an API that would be consistent across Windows, Mac and UNIX whilst cleanly accomodating their differences.

The ZooLib file API doesn't address more esoteric file systems like VMS or IBM's MVS. It models a hierarchical system, with accomodations for special roots (like Windows' UNC paths and Mac Classic's multiple volumes with the same name). Files are byte-oriented, and as with other stream operations ZooLib's file Open and Create return a ref counted streamer object, and optionally an error enum providing more detail in the case of failure. The representation of a pointer to a node in a file system also follows ZooLib's practice of a using a smart object with value semantics.

The ZFile suite was the first place I formalized the notion of a 'trail'. This was another case where it was important to come up with a new name that was suggestive of an existing notion, but distinct enough from it that its different semantics could be defined. Picture a tree; a trail is simply the list of steps to be taken to navigate from some node to some other node. A step is either to traverse the link from the node to its parent, or to traverse the link from the node to one of its children. We represent a step as a string. An empty string indicates a 'bounce', a traversal to the parent of the node. Any other string indicates a traversal to the node with that name. Whether the name is attached to the child node, or attached to the link to the child node doesn't matter in this model.

The notion of a trail through a tree shows up in assets and in the handling of HTTP requests. Theoretically it could also be applied to tuples but I'm not quite ready to harmonize everything to that extent.

January 2002

ZStreamMUX

There's a maxim, a citation for which I can't locate now, which pours scorn on the idea of multiplexing streams over TCP. It kinda made sense when I first saw it, but in these days of ornery system adminstrators and their firewalls that sometimes allow connections seemingly on the roll of a die, there's a lot to be said for the all or nothing of getting a connection to a server, and then sharing it locally.

I wrote ZStreamMUX after coming across an early draft of WebMUX. ZStreamMUX takes a read stream and a write stream, and runs a lightweight protocol over them to support multiple independent sessions. The overall interface is similar to that provided by sockets. The protocol is asynchronous, and uses buffer credits to prevent deadlock at the protocol level.

June 2001

BlockStore: File System in a File

Applications often have to satisfy two conflicting requirements. On the one hand the data created by a user has a structure whose parts should be managed independently of one another, ideally with each piece placed in its own file. On the other hand users like to think of their data as a single entity which can be copied, emailed and backed up in its entirety. Although Mac OS X has the notion of a bundle, a specially marked directory which behaves like a single file when manipulated by the Finder, other operating systems do not.

So, a ZBlockStore takes a single file (or file-like entity) and allows an application to work with resizable blocks allocated within it, easily, efficiently and (with ZBlockStore_PhaseTree) safely.

  • Easy to use — blocks are managed with the same API as real files.
  • Efficient — all the data lives in a wide fan-out B+ Tree.
  • Safe — modifications to nodes in the tree cause the entire ancestor branch to be replicated into existing free space, and the new root is atomically updated only when descendant nodes are known to be in stable storage.

March 2001

Assets: Portable resources

I picked the name 'asset' as an alternative to 'resource', a term that already has too many disparate meanings on different platforms. That said, assets are used in the same situations that MacOS/Win32/BeOS resources would be, although the mechanism is more flexible.

The data making up an asset tree is directly usable by any processor, big or little-endian. It can be kept in a file, loaded into RAM, memory-mapped from disk or accessed from a stream.

December 2000

ZooLib

ZooLib is an Open Source (MIT License) C++ library that makes it easy to write one set of source and build an application for Windows, Mac and UNIX. It provides a foundation suite of facilities that in essence form a virtual operating system API, and wide range of higher-level facilities that build on that foundation.

ZooLib abstracts threads, files, networking, graphics and the user interface. And there are escape hatches whereby OS-specific features can be accessed without compromising the platform-agnostic nature of the rest of the code.

ZooLib has been under continual development since 1992, and incorporates fixes for every OS bug or anomaly I've encountered, and generally provides cleaner mechanisms for most tasks than OSes traditionally provide. It's been the basis of Measurement in Motion, NetPhone, and every version of the Knowledge Forum server and client applications.

September 2000

ZStreamR_Boundary

ZStreamR_Boundary is a ZooLib stream derivative that uses Boyer-Moore-Horspool to take a source stream and efficiently provide to a caller only that data preceding a boundary. This is very useful when parsing MIME multipart streams, which can be nested arbitrarily and otherwise get very fiddly to deal with.

December 1999

BeOS Audio Driver for Sony N505VE

Putting BeOS on a machine that had previously run only Windows was a revelation. Elegant, efficient, and the rarely needed reboots took only seconds. But Be had a small team and their hardware support was focused on the standard modes of common hardware. Laptop hardware tends to be anything but standard. The Sony N505VE was a very lightweight laptop with a good sized screen. Its sound hardware was powerful, but unique and at the time undocumented, and so was entirely unsupported by BeOS. I wrote and open sourced a BeOS audio driver that used the YMF-744B's legacy SoundBlaster emulation to provide 8 bit audio output.

August 1999

NPainter

NPainter is a suite of classes that provides a MacPaint-like interface, but supporting indexed and true color, across all platforms supported by ZooLib.

A key design feature is that it never touches its hosting environment directly. Instead it simply posts update notifications, and so the hosting environment is free to clip or draw on top of a painting as it is being worked on. This makes it easier to host in environments with tricky constraints, and to achieve effects like multiple views onto different parts of the same painting.

May 1999

Windoids: Windows Within Windows...

Measurement in Motion 1.0 had an interesting interface. A document contained a set of measurements, and various objects that could display and modify those measurements. The objects were represented as 'windoids', windows within the document window. MiM 1.0 was a Mac application, so the windoids could depend only on ZooLib's graphics API, with no help from the OS. When demand for a Windows version became overwhelming I implemented a full windowing system that conformed to ZooLib's ZOSWindow API, so that any code that worked within a regular OS window could instead be hosted in a windoid. QuickTime by this point was writing to the screen buffer asynchronously, so any change in the visible region of a windoid is notified before it happens and after its completed, somewhat like the BeOS BDirectWindow mechanism.

August 1998

ZBigRegion

In porting ZooLib to BeOS I found that BeOS's region API was missing key features. Exclusive or and equivalence testing could be handled by composing more primitive operations, but insetting was trickier. So I dug through the X source and found that their implementation of insetting was totally generic, basically shifting the source region for each set bit in the inset distance and accumulating a union (for expanding) or intersection (for contracting).

But BRegion was also quite slow. The internal representation was pretty close to that used by the X code, being a list of non-overlapping rectangles organized into bands. BRegion did not always maintain the same tight constraints as the X code, but it still proved possible to significantly improve performance by manipulating BRegion's internal data using the X code.

By this point I was intimately familiar with X regions and it was a small step to take the X source and rework it, the result being ZBigRegion - a portable region implementation using 32 bit coordinates. Combined with ZDCPixmapBlit it forms the basis of ZDC_ZooLib.

January 1998

ZFiber: Threads At Interrupt Time

Fibers, at least in this context, are threads implemented using setjmp/longjmp to transfer control in a manner reminiscent of co-routines. They are a generalization of the stack-swapping used by NetPhone to run in the constrained environment it experienced when its deferred tasks were scheduled when an application with a tiny stack was current (yes Print Monitor, I'm talking about you).

Whereas NetPhone allocated some space for a stack to be used when invoking a stack-hungry function (the GSM codec generally), ZFiber calls setjmp to record the current stack and registers, then calls longjmp on the setjmp buffer previously initialized by the next fiber to be executed. Because we have complete control over the entire process this makes it very easy to turn async callback-based functions (like most of the Mac's IO subsystem) into blocking function calls. And the whole thing can run at deferred task time, simply by having the callback for an async function schedule a deferred task which calls longjmp to the first fiber that's marked as being both runnable and safe to be run at deferred task time. A fiber can change its deferred task time eligibility on the fly, so sections handling IO can be run at deferred task time, and thus not be subject to the latency imposed by having to wait till GetNextEvent, but sections that have to touch non interrupt-safe sections of the ToolBox can be run exclusively at normal time.

September 1997

ZOSWindow: Abstracting OS Window APIs

ZooLib had always maintained the ZFakeWindow abstract interface between user interface elements and the hosting environment. This allowed ZooLib UI widgets to be used within MacApp applications, standalone applications, Control Panels, XCMD windows and XObject windows. It worked very well.

However, when the portability axis was across platforms rather than hosting environments there was the potential for a lot of replication and ugly code in ZWindow, the standalone application derivative of ZFakeWindow.

So, I abstracted the interface to OS-windows, placing it in ZOSWindow, and modified ZWindow to use a ZOSWindow, rather than be conditionally compiled for different platforms.

January 1996

ZDBase: Portable Database Engine

ZDBase is a relatively simple database storage engine. It's more of an alternative to Berkeley DB (as it was) than a replacement for MySQL. It supports an arbitrary number of tables, records and typed/named fields within those records. Each table maintains as many indices as desired, and the schema can be updated at any time. All data is kept in a blockstore, so everything lives in a single file, and the code and data are portable across platforms.

This was my first serious use of B-Trees, the essential basis of most high-performance disk-based storage systems. The searching of B-Tree content and the insertion of new data is well documented in numerous sources, but the deletion of data is invariably left as an exercise for the reader, which was a bit frustrating but ultimately empowering.

Project Archives