----- Original Message -----
> [...]
> It seems to me that the above "remove direct dependency" items are
> questionable, assuming we're talking about replacing ordinary dynamic
> linkage with dlopen() and such. The dependencies don't disappear, but
> would merely be hidden from the packaging system. Where a user were
> to use the related functionality, she would encounter runtime errors
> as dlopen()s fail. We would lose linker and packaging-enforced
> version matching. We would lose compile-time type checking on
> invoking the dlsym() function pointers.
There is no loss of lib version or function type checking - these are
achieved in the same way we achieve these things for PMDAs, today; as
described in the earlier mail. Dave has effectively already arranged
the libpcp discovery/advertising code this way, just needs the final
steps to be taken now.
But pmwebd is similar - a plugin architecture with clean internal APIs
like we have for pmcd/PMDAs is whats called for there. Increases the
options folks have when deploying PCP components and allows writing
new optional pmwebd "agents" (the graphite/cairo piece would be one
such "agent", with correct external linkage/type checking).
I'm less concerned about webd in the short term though (as you mention
Lukas, it already isolates its dependency chain from the rest of PCP) -
its those core libpcp external dependencies that are more immediately
interesting in terms of container deployments & other minimal footprint
installs (firewalls, NAS boxen and so on).
cheers.
--
Nathan
|