As usual, Frank has beat me to it. In general, he said what I was going to.
On 10/08/2013 11:28 AM, Frank Ch. Eigler wrote:
nathans wrote:
[...]
Initial thoughts are - does this belong in libpcp? Thinking maybe not;
given Avahi is unlikely to be the only auto-discovery model, perhaps we
need a libpcp_discover with an API hiding alternate discovery models [...]
Announcement and discovery are complementary (and asymmetric)
operations, and done by different tools - they need not be together in
the same library at all. But it's convenient if the code were in
-some- library, since chances are multiple tools will deal with
sending announcements (pmcd; future archive-server proxies at least)
and performing discovery (pmlogger or its future manager;
archive-server-capable clients).
As to whether it should be in libpcp or libpcp_foobar, I wonder what
practical consequences exist for either choice. We don't ship/version
them separately.
This is why I put it in libpcp. My initial, initial prototype had it in
pmcd only, but I thought that other PCP servers might want to announce
themselves in the future.
[...] This hypothetical new library might also contain
discovery-mechanism- specific code for catching the advertisement
events and responding to them, in a mechanism-independent way? (so
that this doesn't leak out into other areas of the code base).
At this point, the API consists of a single announce/unannounce pair
only, and it's not really specific to avahi. (Though the _pmcd.tcp
parameter string could be represented or computed internally instead
of being passed.)
Right. The service tag is currently the only avahi-specific thing that
is leaking out. It could be internalized by having the server identify
itself in some other way to the API (perhaps using an enum or something
similar). If/when multiple discovery mechanisms are in play, each
client/server would not need to know which one(s) are being used.
Dave
|