pcp
[Top] [All Lists]

Re: First Cut at Avahi Support for PCP Servers

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: First Cut at Avahi Support for PCP Servers
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Tue, 08 Oct 2013 11:28:33 -0400
Cc: Dave Brolley <brolley@xxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <153661427.3446331.1381221496304.JavaMail.root@xxxxxxxxxx> (Nathan Scott's message of "Tue, 8 Oct 2013 04:38:16 -0400 (EDT)")
References: <5251DF3C.7040805@xxxxxxxxxx> <153661427.3446331.1381221496304.JavaMail.root@xxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
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 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.)


- FChE

<Prev in Thread] Current Thread [Next in Thread>