1. I'm not using git-subrepo for this because most of the protobuf-c
git repository is for the protocol buffers compiler integration,
which we do not need because nats.c already has the generated files
in its source tree.
2. The protobuf-c runtime library is pretty simple, so maintaining its
build process should be quite straightforward. It seems stable as
well, which should simplify the maintenance burden.
3. Not having streaming support is the last major nats.c feature
missing from this project (as far as I am aware). Building this
functionality into the library, even if a nice zig API is missing
(as it is with jetStream as well), can still allow a determined
user to wrap and use the functionality while benefitting from the
zig build system and package manager, which is a win.
I'm going to try out git-subrepo. The main reason for this is that
github's autogenerated tarballs do not include submodules. And
github's autogenerated tarballs are the easiest way to integrate into
the zig package manager. Since git-subrepo checks the files into the
tree directly, new tarballs should include this dependency code.
This builds a very basic version of the nats.c client (no TLS, no
streaming/jetstream/whatever, since those bring in complex
dependencies and I do not need them at the moment). Right now it
contains a simple test program that demonstrates the functionality
(cool!), but the plan is for the nats.zig to bind the API into a
nicer, zig-like shape and re-export it. Then this becomes a package.
The current function could become a test, though it's a bit complex
for a unit test (and requires connecting to an externally-running NATS
server in order to work).
