Hi Charles<br><br><div class="gmail_quote">2012/9/6 Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com" target="_blank">clepple@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sep 5, 2012, at 6:08 PM, Arnaud Quette wrote:<br>
<br>
>> There are also some references to "NUTD", which I think means "upsd".<br>
><br>
> on my request, maybe too much anticipating 2.8 / 3.0...<br>
> the name lib*nut*client  is also part of the naming evolution.<br>
<br>
I've mentioned this before, maybe not on the list: I personally think that renaming the existing binaries and variable names is silly.<br></blockquote><div><br>it depends on what we consider:<br>as per our previous discussions, and feedback from the mailing list, the "NUT" project name will not be impacted.<br>
this "ups" to "nut" move only impact binaries (such as upsd, upsmon, ...), configuration files (ups.conf, ...) and the general terminology used in documentations.<br>I just want to stop advertising that NUT is just for UPS!<br>
this was, and is still, the primary area for NUT. but not the only one ;)<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are we planning on renaming "NUT" because the "U" stands for UPS? If someone with a power device other than an UPS finds the project, they should be able to handle the existing names. In the mean time, we would be making it more confusing for existing users who might have older installations with upsd, and newer installations with nutd.<br>
</blockquote><div><br>lots of people tend to use "nutd" / "nutmon" to refer to upsd / upsmon, which are more logic names.<br><br>The aim is not to confuse even more users, and make things worse, but to clarify/improve the situation, and have more coherent project and naming.<br>
2.8 would be a transition step, still providing ups{d,mon,...} by default, but already providing links using the new nutXXX names.<br>3.0 would complete the transition, by switching by default to the new nutXXX names, and remove compatibility links (optional, may be postponed a bit more depending on users feedback...)<br>
<br>this plan is still open for discussion and comments, as usual.<br>I will create a task or tracker to write this down (I'm still waiting for FusionForge 5.2 to get the Roadmap feature...)<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

libnutclient vs. libupsclient makes a little more sense, given that it's a completely different interface, but the new name doesn't really reflect the higher-level API.</blockquote></div><br>I don't think we need a name that reflect the API level.<br>
in the end, we only want to provide something useful for external interfacing and integration.<br>thus, all the libs and binding will be high level.<br>and libnutclient will also replace the venerable libupsclient for external use.<br clear="all">
<br>cheers,<br>Arnaud<br>-- <br>Linux / Unix / Opensource Engineering Expert - Eaton - <a href="http://opensource.eaton.com" target="_blank">http://opensource.eaton.com</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org" target="_blank">http://www.networkupstools.org</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.fr" target="_blank">http://arnaud.quette.fr</a><br><br>