When use of Protocol Buffers was first suggested back in 2015, I posted
some comments on IBKR's GitHub repository that were fairly critical of
the idea. If you have access to the API repository, you can see these at:
(For those who don't have access, the attached file contains the text
from these posts.)
Most of what I wrote then is still true, but one thing that has changed
is that protobuf compilers now exist for many common languages: for
example WikiPedia says this:
"Protobuf 3.0 provides a code generator for C++, Java (including
JavaNano, a dialect intended for low-resource environments),
Kotlin, Python, Go, Ruby, Objective-C, C#, PHP, Dart.[14] It
also supports JavaScript since 3.0.0-beta-2.[15]
Third-party implementations are also available for Ballerina,
[16] C,[17][18] C++,[19] Dart, Elixir,[20][21] Erlang,[22]
Haskell,[23] JavaScript,[24] Julia,[25] Nim,[26] Perl, PHP, Prolog,
[27][28] R,[29] Rust,[30][31][32] Scala,[33] and Swift.[34]"
So those who develop their own API implementations using such
languages should have no trouble making use of IBKR's protobuf work.
Those who use other languages will be in serious trouble, unless IBKR
commits long-term to allowing use of either the old protocol or the
protobuf implementation. At present, the protobuf implementation
is very limited in scope, and use is optional. But presumably the long-term
goal is to extend the protobuf implementation to all API message types,
and who knows what IBKR will insist on then?
So my overall position is that this is all a big waste of IBKR's time and
effort, for no real benefit. If they were starting to develop the API now,
use of protobuf throughout would be a no-brainer, but after decades
of development using the current protocol I'd say: it ain't broke, so
don't fix it!
Richard
