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.

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

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.

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.

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.