BradyBrenot
commented
6 years ago Split lib and daemon off into own repos: https://github.com/BradyBrenot/libhuestacean https://github.com/BradyBrenot/huestaceand
API definition being drafted (and later finalized) in https://github.com/BradyBrenot/libhuestacean/tree/master/proto
Split the frontend from the backend so that I can split the backend off to a foreground service on Android (#21, #68), and to allow for supporting new frontends (CLI, API).
Here's a stab at this:
IPC / networking
Latency probably isn't a huge deal, as long as it's reasonable. Throughput definitely shouldn't be a huge deal, with one exception (below). It would be neat if this was fast enough to use so generally that one could build entire effects on top of it, just utilizing Huestacean for the spatial jazz and the light communication itself.
Exception -- Visualization
Per #19, there will be a "virtual room" which will be visualizable. Assuming this is a modest texture, packaging that up to send around locally may be prohibitively expensive.
Maybe, instead, use shared memory. Of course Qt has a nice cross-platform class for that: http://doc.qt.io/qt-5/qsharedmemory.html
gRPC
I like gRPC for this, it seems like a nice pragmatic choice. It's not as blindingly efficient as a tightly-packed custom protocol could be. It's not as efficient as some other competitive RPC frameworks (e.g. Cap'n Proto). It is:
Using gRPC for IPC means it's also available for networking, which is where it really shines. I like not having two separate interfaces, IPC and Network should just be the same thing for my sanity.
TLS
It doesn't look like gRPC C++ server can do TLS-PSK, which leaves me with somehow exchanging certs between the server and client.
Exchange cert on local machine
Can use QSettings across multiple processes.
Exchange cert between devices
Well this one's just hell, though.
Rather than dealing with hell, I could have a server that handles this, drop it on GCP. Server could auth a user, then let them upload or download a cert. If it was light enough to keep me in free tier that'd be terrific. There would also need to be a method to exchange certs manually.
This solidly pushes secure communications into "worry about later" territory. For now, do not use TLS, bind on loopback, maybe give a checkbox to bind on all available.
libhuestacean
The client gRPC code should be contained in a nice friendly C++ library that the frontend uses to talk with the backend. It would also contain the QtSharedMemory stuff, although Qt wouldn't be exposed in its API. This friendly library would also act as another means by which others could interact with Huestacean. So I'd be providing two APIs:
For the convenience of all involved, the lib would share several files with the backend (or vice-versa or however you want to word this); this would include many common types and probably various helper functions (e.g. color space-related)
API
Defined in https://github.com/BradyBrenot/libhuestacean/tree/master/proto; I'm just drafting the API directly as a protobuf, so this is where both the draft and actual definition will be.
huestaceand
Includes all the stuff that actually talks to the lights, and handles screen sync.
Frontend - GUI
QtQuick GUI, as before (although one hopes I'll take the time to make it a little less crap)
Will start the Backend if there's not one already running, but:
Frontend - CLI
Console application, can talk to a running Huestacean service.
Semver
Just as an aside, if I'm actually providing an API in v3.0, I should start using semver instead of this poorly-enforced "MAJOR.BUG" thing.