similar to: On retiring some terminology

That is terminology from Computer Science. (Decades ago?) It is familiar. Not invented by Cisco. As in, producer-consumer, from the same time. Those were all different paradigms for client-server relationships. There must be Wikipedia citations that can be consulted. As I recall, there were distinctions, such as, producer-consumer were tightly bound, where the producer had no purpose

That is terminology from Computer Science. (Decades ago?) It is familiar. Not invented by Cisco. As in, producer-consumer, from the same time. Those were all different paradigms for client-server relationships. There must be Wikipedia citations that can be consulted. As I recall, there were distinctions, such as, producer-consumer were tightly bound, where the producer had no purpose

There is, https://en.m.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern I said I stayed away from it because of the Cisco link. Others as well as you are free to persue it. I was just making suggestions. On Fri, Mar 12, 2021, 10:43 PM Baker, Lawrence M <baker at usgs.gov> wrote: > That is terminology from Computer Science. (Decades ago?) It is > familiar. Not invented by

There is, https://en.m.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern I said I stayed away from it because of the Cisco link. Others as well as you are free to persue it. I was just making suggestions. On Fri, Mar 12, 2021, 10:43 PM Baker, Lawrence M <baker at usgs.gov> wrote: > That is terminology from Computer Science. (Decades ago?) It is > familiar. Not invented by

Thank you for the suggestions, keep them coming :) To me, I think I considered pub-sub but it did not quite fit - gotta refresh my memory by code re-reading (or expert comments) - I found I'm vague now on who hits the big red button to shout that a particular power source device got critical - the upsmon in "master" role, or "upsd" that talks to all subscribed (indeed!)

Thank you for the suggestions, keep them coming :) To me, I think I considered pub-sub but it did not quite fit - gotta refresh my memory by code re-reading (or expert comments) - I found I'm vague now on who hits the big red button to shout that a particular power source device got critical - the upsmon in "master" role, or "upsd" that talks to all subscribed (indeed!)

So, for the past couple of days the SurveyMonkey results are not changing, with 13 replies overall. Should we wait for more or everyone passionate enough has already spoken? In practice I'd likely follow up on a weekend anyway, but... the weekend is coming! :) Currently we have a clear leader pair that collected almost half the votes (6), two votes were to keep old words in place - alas,

So, for the past couple of days the SurveyMonkey results are not changing, with 13 replies overall. Should we wait for more or everyone passionate enough has already spoken? In practice I'd likely follow up on a weekend anyway, but... the weekend is coming! :) Currently we have a clear leader pair that collected almost half the votes (6), two votes were to keep old words in place - alas,

Jim, The terminology I recall for that one-to-many relationship is publisher-subscriber. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov<mailto:baker at usgs.gov> On Mar 12 2021, at 6:24:38 PM, Phil Stracchino via Nut-upsuser <nut-upsuser at alioth-lists.debian.net<mailto:nut-upsuser at alioth-lists.debian.net>> wrote: This email has been received from

Jim, The terminology I recall for that one-to-many relationship is publisher-subscriber. Larry Baker US Geological Survey 650-329-5608 baker at usgs.gov<mailto:baker at usgs.gov> On Mar 12 2021, at 6:24:38 PM, Phil Stracchino via Nut-upsuser <nut-upsuser at alioth-lists.debian.net<mailto:nut-upsuser at alioth-lists.debian.net>> wrote: This email has been received from

I didn't go there due to its use by Cisco. On Fri, Mar 12, 2021, 10:03 PM Baker, Lawrence M via Nut-upsuser < nut-upsuser at alioth-lists.debian.net> wrote: > Jim, > > The terminology I recall for that one-to-many relationship is > publisher-subscriber. > > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > > On Mar 12

I didn't go there due to its use by Cisco. On Fri, Mar 12, 2021, 10:03 PM Baker, Lawrence M via Nut-upsuser < nut-upsuser at alioth-lists.debian.net> wrote: > Jim, > > The terminology I recall for that one-to-many relationship is > publisher-subscriber. > > Larry Baker > US Geological Survey > 650-329-5608 > baker at usgs.gov > > > > On Mar 12

On 3/12/21 9:14 PM, Rusty Bower wrote: > Manager/subscriber seems most accurate > > Sent from my iPhone > >> On Mar 12, 2021, at 20:13, Douglas Parsons <doug at parsonsemail.com> wrote: >> >> ? >> In place of secondary how about subscriber? It would be accurate to >> the role. I'd been going to suggest controller and ... something.

On 3/12/21 9:14 PM, Rusty Bower wrote: > Manager/subscriber seems most accurate > > Sent from my iPhone > >> On Mar 12, 2021, at 20:13, Douglas Parsons <doug at parsonsemail.com> wrote: >> >> ? >> In place of secondary how about subscriber? It would be accurate to >> the role. I'd been going to suggest controller and ... something.

Hello fellow NUTs :) Some time ago an issue https://github.com/networkupstools/nut/issues/840 was raised, and with current work underway to publish a standard on NUT protocol it became more urgent - to retire the master/slave terminology from NUT configuration and documentation. I looked around for suitable synonyms, and for our primary use-case with upsmon roles - where it either manages an

Hello fellow NUTs :) Some time ago an issue https://github.com/networkupstools/nut/issues/840 was raised, and with current work underway to publish a standard on NUT protocol it became more urgent - to retire the master/slave terminology from NUT configuration and documentation. I looked around for suitable synonyms, and for our primary use-case with upsmon roles - where it either manages an

Thanks again for all the suggestions. For now I've prepared draft PRs, mostly to map out where the changes are needed - based on my earlier work with the originally proposed terminology. Now that we know where to change it, should not be too great a hassle to replace again by some other choice... subordinate was a bit too long to type :) To make the election of team choice more simple, I

Thanks again for all the suggestions. For now I've prepared draft PRs, mostly to map out where the changes are needed - based on my earlier work with the originally proposed terminology. Now that we know where to change it, should not be too great a hassle to replace again by some other choice... subordinate was a bit too long to type :) To make the election of team choice more simple, I

An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220323/c7ad42ec/attachment.htm>

That's odd, seems a spam or phish sneaked through to the list. NOT from me :) Jim On Wed, Mar 23, 2022, 21:38 Jim Klimov via Nut-upsuser via Nut-upsuser < nut-upsuser at alioth-lists.debian.net> wrote: > Hello again, > Please find lower the overall documentation: > > > >