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.

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.

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.

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.

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.

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.

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.