Nut upsdev - Jan 2007 - upscli_splitname() for upsc_list (was: Re: Default NUT PORT)

On 1/13/07, Peter Selinger <selinger@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

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@localhost". I would be
very
happy if "localhost" were the default. 

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.

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

-- Peter

Charles Lepple wrote:
> 
> On 1/13/07, Peter Selinger <selinger@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@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>