Here a list of some things I’ve noticed:
* The already mentioned Server -> ServerCLI -> Server cycle I mentioned in
the other tread
* The “conf” package contains both configuration model classes, but some
“checks” (passive) which actually more are “tasks” (active)
* The “Check” classes in the config package are only used by the CLI
operations (They should be moved in some sort of “tasks” package relative to
the CLI implementation
* In the config node the RPC stuff is located in a “thrift” package which
doesn’t sensibly give any information on what it does (We should rename that to
something “rpc” or “rpcserver”
* The same RPC classes are located alongside the DataNode class (We should
move them into the same package sub-name as we do for the config node)
* In the DataNode all of the sub-services RestService, RPCService,
MQTTService, … are all located parallel to the main DataNode class which uses
them
* I would propose to define and use a “Service” interface and have this
implemented by all sub-services.
* I would propose to move stuff such as the MQTT Service, RestService, …
into separate maven modules.
* This would allow us to provide differing implementations such as an
MQTT subsystem, that provides its own MQTT server (like we currently do) or a
version that simply acts as a Client to an existing MQTT infrastructure
* In the DataNode module it feels like the “protocols” package doesn’t
really contain any protocol, but client stubs of different type (which
themselves partially use different protocols in the end)
* I would propose to move some of these out into separate modules, just
like the “Services” that use them.
* The DataNode protocols package contains clients for ConfigNodes (cn) and
DataNodes (dn) which feels slightly odd (I assume this is because a client
always connects to a DataNode in order to execute operations … even operations
on other DataNodes and ConfigNodes). Possibly a separate CLI module would be
more appropriate?
