[Nut-upsdev] upscli_splitname() for upsc_list (was: Re: Default NUT

[Charles Lepple]

On 1/13/07, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> For some time, I have considered making a dual suggestion: to make the
> hostname optional. For a large percentage of users, the hostname is
> always equal to "localhost". I don't know how many times I mistakenly
> typed "upsc apc" instead of "upsc apc at localhost". I would be very
> happy if "localhost" were the default.

Agreed, localhost makes sense as a default, since that's the most
likely host for testing drivers.

> But this conflicts with your suggestion, because according to your
> scheme, apc would be interpreted as the hostname, and the upsname
> would be NULL.
>
> I think there should be two different functions for this reason.  They
> can reuse each other because upscli_splitname can check for "@" and
> then call upscli_splithostname for the after-@ part. Also, the
> addition of a new upscli_splithostname function would be backward
> compatible for existing clients.

Ah, good call - I hadn't thought about calling upscli_splithostname
from upscli_splitname.

> To be clear: the syntax I am suggestion for upscli_splitname is
> upsname[@hostname[:port]], not upsname[@hostname][:port], although the
> latter certainly would also make sense (but then the code couldn't be
> reused as easily).

OK. I tend to agree that if you're specifying a port, you should
specify a hostname.

Another extension of this would be to use the first ups.conf UPS
definition as the default, making the syntax
"[upsname[@hostname[:port]]]" - again, considering that most users
will be using their only UPS on localhost. But I have a feeling that
it would be too complicated to tie in the default upsname in
upscli_splitname (unless we returned NULL for upsname), so maybe we'll
leave that alone as well.

> Charles Lepple wrote:
> >
> > On 1/13/07, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> > > > The question is when exactly this should be converted to a number.
> > > > Should this be done in upscli_splitname() or in upscli_connect()?  The
> > > > latter would require a change in the prototypes of upscli_splitname()
> > > > and upscli_connect(), and an attendant change in all the existing
> > > > clients. When changing the "port" argument to a string, the API should
> > > > also define whether this is allocated (and must be freed) or not.
> >
> > This reminds me: when I was working on branches/upsc_list, the
> > upscli_splitname() function has this comment:
> >
> > /* split [upsname@]hostname[:port] into separate components */
> >
> > To me, this implies that "upsname@" is optional, but I think this is
> > left over from an older version of NUT (since you have to specify an
> > upsname for upsc).
> >
> > I was thinking that listing all available upsnames would be done like
> > this: "upsc -l hostname[:port]".
> >
> > In order to reuse the upscli_splitname() code, I was thinking that I
> > could modify it to simply return NULL in *upsname if there is no '@'
> > sign. The alternative would be to have a flag (also an API change) or
> > create upscli_splithostname().
> >
> > Since libupsclient isn't exactly ubiquitous, I would prefer changing
> > the semantics of upscli_splitname() and fixing whereever it is called
> > to check for a null upsname. Opinions or objections?
> >
> > --
> > - Charles Lepple
> >
> > _______________________________________________
> > Nut-upsdev mailing list
> > Nut-upsdev at lists.alioth.debian.org
> > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
> >
>
>


-- 
- Charles Lepple