Hello
> Instead of having users rebuilding the tcpborphserver program every time they
> add or change a custom command, I would like to propose a plug-in
> architecture for tcpborphserver. This would allow users to create shared
> libraries that the tcpborphserver executable could load *at runtime* to
> register new commands with tcpborphserver. This keeps the tcpborphserver
> program lean and focused on the core functionality, yet allows different
> sites to provide and use their own site-specific customizations to
> tcpborphserver3.
So we have been thinking about this (and actually the kcs code does
use dlopen), but two things are giving us pause:
1 - The .so files will have to be compiled, and if the toolchain and libraries
used to build the .so files differ substantially from what was used to build
tcpborphserver itself, we are likely to encounter interesting failures. And
given that some people will use cross compilers while others native ones, I
expect that this will occur more often than in normal environments
2 - Similarly, if the katcp headers (defines, prototypes) differ between server
build and module build, we are looking at support issues. Consider a data
structure which acquires an extra field between server and module build -
accessing that data structure will result in core dumps in the best case
Using big software engineering words: I think the codebase isn't yet mature
enough and userbase isn't yet large enough to tilt the cost/benefit balance
toward using shared objects. I'd like to stress the word "yet"... and I am also
operating under the assumption that we are opensource throughout - I don't
believe we have organisations which would like to write closed-source
modules for distribution/sale to other organisations - a reasonable
assumption as the license doesn't permit it :)
Having said this: I think adding module loading support is quite easy, and
you are welcome to add it:
At the end of raw.c add a register_flag_mode_katcp call to a new function,
(say "load_request_cmd"), which then does the dlopen on a given
filename, extracts a symbol, maybe even computes it from the filename, say
filename_cmd, and then does a register_flag_mode_katcp on that symbol -
that should allow anybody to load an additional command by going
"?load-request name", where name.so is an object implementing name_cmd
to provide a ?name request.
Easy, and good enough to use within a single organisation. With git push pull
magic anybody who thinks this is useful should be able to grab it.
The more demanding work is to make shared objects code useful for third
parties: Making sure that there is logic/magic to test that incompatible APIs
or API revisions are not being used, that all data accesses happen via calls to
opaque pointers, not directly to data structure members (see point 2) and
that the API is sane ... I'd expect that I'll end up reworking said
API once or
twice before we are happy with it and can declare it stable (which is what
shared objects rely upon).
regards
marc
