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.

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.

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.

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.

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.