<div dir="auto">Sounds reasonable to me, and hopefully might be aliased in a legacy-compatible manner (client asks with new command, if rejected try old; accept both words on server side) so it could happen in current master.<div dir="auto"><br></div><div dir="auto">Note that similar protocol changes e.g. for master vs primary were just planned as a theoretical construct, but I did not code any PoC (beside commenting the idea) nor saw any PRs to such effect.</div><div dir="auto"><br></div><div dir="auto">Bite-size contribution that would be a little coding and a lot of testing (combining new and old binaries as servers and clients) is welcome :)</div><div dir="auto"><br></div><div dir="auto">Jim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 29, 2021, 11:00 Roger Price <<a href="mailto:roger@rogerprice.org">roger@rogerprice.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 26 Jun 2021, Manuel Wolfshant wrote:<br>
> On 6/26/21 10:26 AM, Roger Price wrote:<br>
>> On Fri, 25 Jun 2021, Mark Hansen wrote:<br>
>>> On 6/24/2021 5:48 AM, Roger Price wrote:<br>
>>>> Comment: had the command LOGIN been called SETACTIVE, with the <br>
>>>> upsmon flag ST_LOGIN changed to ST_ACTIVE, and NUMLOGINS changed to <br>
>>>> NUMACTIVE this mechanism would probably be easier to understand.  <br>
>>>> LOGOUT might be NOTACTIVE.<br>
>>>><br>
>>>>     Current   Proposed<br>
>>>>     LOGIN     SETACTIVE<br>
>>>>     LOGOUT    NOTACTIVE<br>
>>>>     NUMLOGINS NUMACTIVE<br>
>>>>     ST_LOGIN  ST_ACTIVE<br>
>><br>
>>> What about:<br>
>>>     Current    Proposed<br>
>>>     LOGIN      ATTACH<br>
>>>     LOGOUT     DETACH<br>
>>>     NUMLOGINS  NUMATTACHED<br>
>>>     ST_LOGIN   ST_ATTACHED<br>
>><br>
>> Better.  ATTACH is simpler and clearer than SETACTIVE.  Roger<br>
><br>
> +1 !<br>
<br>
Jim, I would like to suggest this as a change to NUT - not something to be done <br>
for the next release, but, like some other things in the draft RFC (I-D), as a <br>
statement of direction for the project.<br>
<br>
If the project as a whole can agree on this, I will make the change LOGIN -> <br>
ATTACH in the I-D with a note saying that current practice is to use LOGIN.  Do <br>
we need to vote?<br>
<br>
Roger_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>