Don Box recently reminded me of my involvement in the Apollo Network Computing Architecture (NCA). I never worked on NCA itself -- that was reserved for people much brighter than me, such as Nat Mishkin and Paul Leach. Rather, I was only a user of the Network Computing System (NCS), Apollo's NCA implementation.
Back then, I was a hardware/software guy, writing both regular applications and embedded applications. Several years before, I had started my career working on advanced development chips for Texas Instruments, but I eventually discovered that software was both fun and challenging, and gradually switched over to it. At Apollo I worked on both hardware and software. One of my tasks there was to develop a distributed hardware debugger. This application had to run on a regular workstation and communicate with another workstation that was shut down and running only a remote service monitor on its Motorola 68020 service processor. The service monitor had to fit within only 22k of RAM (yes, i said kilobytes).
My first attempt to solve this was to stick a trimmed-down NCS server into the 22k and use RPC to send debugger commands over to it. It worked, but not entirely. The problem was that some perfectly valid and desirable debugger commands could hose the electrical operation of the bus that the network card sat on, which meant that the pings that NCS (and later DCE and COM) sent from client to server would not get through. When the pings failed, the client failed, because it assumed that the server was dead due to the lack of response to its pings.
I attempted to solve this by modifying NCS to make a flag available to turn off pinging. My changes worked technically, but Paul Leach nearly took my head off for them. He explained that NCS was a widely used system and turning off pings would break the protocol. My counter-argument was that the way I had implemented it (using a global shared library variable feature available only in Domain/OS), nobody would even know they had the capability to turn off pings. Nevertheless, the changes were deemed unacceptable, and they never made it into the code base.
I ended up writing my own protocol, which worked extremely well. The project was a big success, especially given that two similar attempts had been made before it and both had failed. I wrote about the project, which was called RISE++, in an article in the IEEE Design & Test of Computers magazine in the early 1990s. If any of you reading this are hardware geeks, "RISE" stood for "remote interactive scan enviroment," and it allowed hardware engineers to use the scan design features of the workstation under test to have virtually complete control over the state and the clocking of the hardware, to the point where they could single-step the hardware itself. Coincidentally, RISE++ also included one of the first uses of Tcl and C++ together, well before there were any public packages available for using Tcl with C++. At the time, John Ousterhout, the creator of Tcl, turned down my offer of Tcl codebase modifications to accommodate C++, essentially stating that he didn't think anyone would ever want to use Tcl and C++ together. Oops, wrong guess there! :-)
Anyway, what my experience with NCS for RISE++ taught me was that protocols can't ever be "one size fits all." The NCS protocol could not work for my application because it required pings, which my hardware couldn't handle. This fundamental realization eventually led to my work to develop multi-protocol middleware, which represents a significant part of my work over the past dozen years. For example, I believe I was the very first to create an ORB that interoperated between two vendors, years before the Internet Inter-ORB Protocol (IIOP) was created, by crudely cramming both IBM's Distributed System Object Model (DSOM) ORB and HP's Distributed Object Management Facility (DOMF) ORB together into the same address space so that any messages arriving would be handled by one or the other appropriately depending on the target. Crude, yet effective. This work eventually led to HP's ORB Plus product, which included amazing multi-protocol and multi-transport support thanks in large part to the extremely brilliant minds of Keith Moore and Evan Kirshenbaum, and then later led to IONA's Adaptive Runtime Technology (ART) which supports even greater flexibility and dynamic pluggability. ART is of course what underlies our Orbix and Artix products.