Technical details

The nitty gritty trade secrets and IP, for nerds

RTD = RealTimeData

Excel has mature realtime data support, exposed through the =RTD function. This (usually) connects to a local COM automation server running inside the Excel process, which posts updates to Excel as they arrive from some external source.

At a set interval (default is a leisurely 2s), Excel refreshes and displays/recalculates with any queued up values.

rtd.pub provides a COM server (also known as an RTD server in this context as it implements IRtdServer) through an installer. It is generic and saves you from having to do any Windows development, if that isn't your bag.

RTD server and communication

The rtd.pub RTD server is a thin conduit that delegates the bulk of its implementation to a local plugin host, written in go. The RTD server is written in C# and runs inside Excel.

By design, it is kept deliberately lightweight and simple. The simplicity of the add-in helps to provide excellent performance, and the overall design approach provides isolation from badly behaved plugins or data sources.

The RTD server connects to a plugin host, which in turn supervises the plugin subprocesses, aggregating their output into a single, debounced stream which is consumed by Excel.

IPC between Excel and the plugin host, and the plugin host and plugins is achieved through gRPC over Unix sockets.

The key idea is to keep the interesting parts of the implementation outside of Excel. The add-in is effectively a dumb terminal.

Plugins and connectors

A plugin is an executable started by the plugin host, based on connector configuration.

A connector is a named, reified instance of plugin— for instance, the connector nats-dev is an instance of the nats plugin.

Connectors run alongside the rtd.pub add-in as separate, local processes, each connecting out to the ultimate source such as a NATS server, Kafka cluster or external data vendor.

Multiple connectors services can be used from the Excel add-in, through their connector name. The plugin host selects which connector to use through the first parameter included in a rtdpub.Sub call. This keeps things simple and generic on the Excel side.

=rtdpub.Sub("nats-dev", "some.dev.subject") # a nats connector
=rtdpub.Sub("time-of-day", "bst") # a clock connector

To make your solution more user-friendly, streams can be added to connectors. This is essentially a documented alias to the above function calls. For example =acmeco.TimeOfDay("bst") is equivalent to =rtdpub.Sub("time-of-day", "bst") but a little more discoverable, as well as giving the author the chance to add documentation about the parameters.

You can write plugins in any language that supports gRPC, which is most! It is advisable, however, to use our Go and Python SDKs, which will be available soon. See more about configuration in integrations and writing a plugin.

Mac support on the way

There's no Mac support at this time due to the underpinning RTD technology being based on COM automation.

Why? Isn't this prehistoric dinosaur tech? Yep. 🦕 Shouldn't you be using the latest Office.js add-in approach? Nope, not on Windows in our humble opinion.

Even Microsoft acknowledge that in some scenarios, the JavaScript architecture is not always the better choice over the rusty and trusty XLL/COM stuff. Windows desktop-based Excel is the most common install base in many industries. Old school RTD is still arguably the the most performant way and best understood (if idiosyncratic, to be polite) way of streaming data into Excel.

Mac support will be via a gRPC to websocket bridge. Early indicators show that it performs well enough in lower volume and velocity scenarios. We will have some more benchmarks when it is ready for an initial release.

This does not impact how plugins are written. The same plugins will run on any platform supported by your chosen implementation language. For now, though, the resulting binaries/Python modules simply need to be able to run on Windows.