Transfers (by subscribers) use perfect forward secrecy, and can be entirely asynchronous, so sender and receiver need never be online at the same time. Of course if they are, then transmission goes as fast as the physical network allows.

We built the backend and client mainly in Python, supporting Mac and Windows back to 10.5 and XP respectively. For Linux we support 32 and 64 bit Ubuntu 12 and later.

Much of my focus has been on keeping OS variations from impacting the main body of the code. To that end, we're using wxWidgets to abstract the GUI, and I've implemented such native code as needed to interface with unwrapped aspects of the OS and third-party libraries. In some cases the fluent Python bindings to OS facilities just aren't fast enough, and native code is used there also.

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.

Generally a proxy is a long-running system service, and it builds and evolves knowledge of what outbound paths and upstream proxies are available and usable. This proxy launches when the device connects, and shuts down when it quits, so any knowledge it can acquire is likely to be stale.

The approach I took was to try everything at once -- initiate connections on every combination of network interface, proxy name and resolved IP address, and use whichever wins the race. Thereafter it starts with the last thing that worked, and only scatterguns after a timeout. Interestingly this makes regular desktop browsing more responsive too, but it's pretty abusive to the network infrastructure and is only safe for idempotent GETs.

The other interesting feature was handling Proxy Auto Config (PAC) files. These are chunks of javascript that take a desired host name and return the name/address of the proxy that should handle the request. I'd never come across one in the wild, but they're very common in corporate networks where there's free rein inside the firewall, but all external access is via proxies. The system facilities on OS X are sufficient that the task can be handled by calling CFNetworkExecuteProxyAutoConfigurationURL. Windows on the other hand can almost do the job. The WinHTTP library can handle a PAC specified with a network URL, but not with a local file. So when we see that the PAC is a local file we fabricate an HTTP URL referencing a port we're handling, and any request on that port returns the content of the PAC file.

Zorap ran as a browser extension, so could be instantiated and destroyed many times within the life of a process. Any code it used had to be robust, and could not depend on operating system facilities to dispose of resources like network sockets.

The BlackBerry application is written in Java. It maintains a single communications channel with the Mac application, over which it receives requests to make, use and break network connections. The channel is multiplexed with ZooLib's Java ZStreamMUX on the BlackBerry side, and its C++ ZStreamMUX on the Mac.

Much of the Mac application's functionality is a C++ HTTP and port-forwarding proxy server, most of which is in ZHTTP. Its UI is implemented in Objective C using Cocoa Bindings.

The remainder of the Mac implementation effort was in reverse-engineering the BlackBerry/Host USB communications protocol.

New features included support for upload and download of files as attachments to views and notes, headings within views, full text and attribute-based searches, and notification by email. It also supported graphs of useful metrics, implemented across platforms using ZDC_ZooLib.

On the back end, a significant change was moving from the original blockstore implementation to one based on B+Trees that uses a neat upward propagting copy-on-write of nodes to make it virtually bullet-proof - only a physical failure of the backing store can cause data loss.

For a time we had native client and web access running simultaneously, but never in a released version. The 3.x client remains buildable as of May 2006, but still talks only to a 3.x server.

By this time ZooLib abstracted Mac OS, Windows and UNIX, so the server could be hosted on all three OSes.
The text editing in Knowledge Forum 3.0's note windows used the PAIGE text engine, which was a fairly crusty 60,000 lines by this time, but was portable across Mac and Windows. So although the rest of the client could be built for UNIX, without the text editor it wasn't particularly useful and we never released a UNIX client, although that wasn't a big deal in 2000.
Unfortunately we also had to abandon Kevin Parichan's excellent painting implementation, as it was also Mac-specific. Instead we used ZooLib's NPainter, which used only ZooLib features and was thus completely portable.

CSILE was pioneering and innovative, but in May 1994 limitations in its feature set and a desire to see it in wider use led to a collaboration with Learning in Motion to redesign it. The scope of the necessary changes neccessitated a complete reimplementation and the decision was taken that it would be released as a commercial product.

Cyrus Ghalambor started work on the KF 2.0 client application in July 1995. I was busy with NetPhone till December 1995, when I started working full time on the client's data API and the server that would satisfy its requests. We looked at several existing database libraries, but they were either too limiting or could not run on Mac OS (Classic, of course). So I implemented ZDBase, a portable database engine that was built on ZooLib. Client and server communications and the server's administration UI were also built using ZooLib.

The client application's event loop, menus and windows were handled by a refinement of Berkeley Systems' Zoom framework. It had two main types of windows. The note window used Zoom for its controls, and the WASTE text engine for its text editing panel. The view window provided a two-dimensional icon-based representation of collections of content, its operation was closely modeled on that of Apple's Finder, and it was implemented using ZooLib. The note and view windows also contained pictures, in-line with the text in the note window and in a layer behind the icons in the view window. Pictures were edited in place using a nice painting implementation by Kevin Parichan.

Other dialogs and property inspectors were based on Zoom or ZooLib, depending on whether they were written by Cyrus or by me.

The code that did the work was a simple WDEF whose structure region was taken from the main screen's bounds and whose draw method filled in the extra space with a color or pattern. Director itself was completely oblivious to the change, it just saw a window with a very, very thick border. Most of the development work was actually in the installer application, which added the functionality to the standalone playback 'projector' with a simple drag-and-drop, and in the XObject that provided runtime control of the border.

I revised FinderHider a couple of times in response to customer requests, adding support for non-rectangular borders, transparency in the stage itself, and for use in HyperCard and Authorware titles.

It was the commercialization of a project from the BBC's Interactive Television Unit called 'Future Worlds'. Future Worlds was investigating how to create video content that could be used in a traditional linear documentary and also in a hyper-linked computer-based environment. I worked at the BBC for all of three months before the ITU was spun off into an independent company, the MultiMedia Corporation. MediaMaker was published by MacroMind, and I went along with it to San Francisco.