[Nut-upsdev] renaming (was Re: [nut] High level C and C++ libnutclient (#2))

[Arnaud Quette]

Hi Charles

2012/9/6 Charles Lepple <clepple at gmail.com>

> On Sep 5, 2012, at 6:08 PM, Arnaud Quette wrote:
>
> >> There are also some references to "NUTD", which I think means "upsd".
> >
> > on my request, maybe too much anticipating 2.8 / 3.0...
> > the name lib*nut*client  is also part of the naming evolution.
>
> I've mentioned this before, maybe not on the list: I personally think that
> renaming the existing binaries and variable names is silly.
>

it depends on what we consider:
as per our previous discussions, and feedback from the mailing list, the
"NUT" project name will not be impacted.
this "ups" to "nut" move only impact binaries (such as upsd, upsmon, ...),
configuration files (ups.conf, ...) and the general terminology used in
documentations.
I just want to stop advertising that NUT is just for UPS!
this was, and is still, the primary area for NUT. but not the only one ;)

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.
>

lots of people tend to use "nutd" / "nutmon" to refer to upsd / upsmon,
which are more logic names.

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.
2.8 would be a transition step, still providing ups{d,mon,...} by default,
but already providing links using the new nutXXX names.
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...)

this plan is still open for discussion and comments, as usual.
I will create a task or tracker to write this down (I'm still waiting for
FusionForge 5.2 to get the Roadmap feature...)

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.


I don't think we need a name that reflect the API level.
in the end, we only want to provide something useful for external
interfacing and integration.
thus, all the libs and binding will be high level.
and libnutclient will also replace the venerable libupsclient for external
use.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120906/de444584/attachment.html>