Nut upsdev - Oct 2013 - UPSC based Windows Client

[attachments trimmed]

Begin forwarded message:
> From: eric kreuwels
> Subject: UPSC based Windows Client
> Date: October 13, 2013 4:43:31 PM EDT
> To: nut-upsdev at lists.alioth.debian.org
> 
> 
> Dear developers
> 
> Last month I wrote WinUPSC, a Windows task tray UPS monitor. WinUPSC
re-uses the UPSC logic to poll the UPS.
> This initial version was tested against two Eaton UPS devices connected to
my NAS device. 4 PC's monitor the UPS they are depending on,
> WinUPSC is now robuust enough to deal with all kind of circumstances (e.g.
continue after standy, hibernation, disconnects etc).
> 
> I really appriciate the NUT initiative and would like to actively
contribute with this tool, but never published code to the open source community
before. Can it be included in the NUT Windows distribution? Or just a link to
e.g. sourgeforge on the Downloads page? The minimal requirement for me is to be
able to continue to develop and publish updates. Preferably others can
contribute as well
> 
> Both sources (C++/MFC in VS2010) with a manual and installer (renamed to
msi_) are attached (no executables included). Please contact me how to proceed.
I would like to publish my sources, installer and manual via the NUT website,
free for everyone.
> 
> Best regards
> Eric Kreuwels 
> (Senior SW developer)
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20131013/09593f2b/attachment.html>

Hi Eric,
> Last month I wrote WinUPSC, a Windows task tray UPS monitor. WinUPSC
re-uses the UPSC logic to poll the UPS.
> This initial version was tested against two Eaton UPS devices connected to
my NAS device. 4 PC's monitor the UPS they are depending on,
> WinUPSC is now robuust enough to deal with all kind of circumstances (e.g.
continue after standy, hibernation, disconnects etc).

Sounds great!
> I really appriciate the NUT initiative and would like to actively
contribute with this tool, but never published code to the open source community
before. Can it be included in the NUT Windows distribution?

Hopefully one of the NUT Windows developers can chime in. I am not familiar with
the details of how the Windows package is built.

I don't know of any policy reasons why it couldn't be included. I saw
that your code is GPL v2+, so that's good.
> Or just a link to e.g. sourgeforge on the Downloads page? The minimal
requirement for me is to be able to continue to develop and publish updates.
Preferably others can contribute as well
> 

We can definitely add a link to somewhere, at the very least.

As for updating it, I think it depends on what you prefer. If you want to use
Git, we could probably add this source code to the NUT GitHub site. If you are
more comfortable with Subversion or Mercurial, there are other hosting options.

It also depends on how much code is shared with the core of NUT. There are a few
Windows compatibility functions on the windows_port branch in Git, but I
didn't look closely to see how much of that you are using, or if you made
equivalent modifications to the main NUT/upsc codebase.
> Both sources (C++/MFC in VS2010) with a manual and installer (renamed to
msi_) are attached (no executables included). Please contact me how to proceed.
I would like to publish my sources, installer and manual via the NUT website,
free for everyone.
The mailing lists limit messages to ~40 KB, so your source code didn't make
it through (sorry I forgot to mention that at first). If you have a Google
account, I think you can post the files on Google Drive. This is probably the
easiest until source control is completely set up, since I don't have access
to post the files on networkupstools.org. If that doesn't work, let me know
and I can put them in a temporary directory on my server. We can work with
Arnaud to get the installer and manual on the main NUT site later.

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20131014/63b36026/attachment.html>

[Please remember to copy the list.]

On Oct 15, 2013, at 8:45 AM, eric kreuwels wrote:
> Hi Charles
>  
> Thanks for your answer. Good questions/suggestions. I copied both the
WinUPSC and the installer project on my GDRIVE and shared it with you:
>
https://docs.google.com/file/d/0B0mSjYYj84-6ZGM4MWZfMnFxbUU/edit?usp=sharing
>  
> Archiving WinUPSC in the NUT GitHub would be my preference. Delivery as
part of te Windows distribution is basically a separate decision for you guys.
>  
> Steps I have in mind:
> Check how WinUPSC will is perceived by the other developers! Then decide to
setup a project in NUT GitHub
> Maybe a good idea to have a code review:
> Especially how I modified the UPSC code for polling. For example how
standardized is the parameter list? I made assumptions here.
I haven't diffed your code against either NUT or WinNUT, but after a quick
check, I'm not sure I understand your question here. If you are referring to
the UPS variables, there is no guarantee that a specific variable will be
available (except "ups.status"; think of a contact-closure UPS which
can only report OL/OB/LB).

As an aside, in upsc.c, you use sprintf() with strlen(). There is a
snprintfcat() utility in common/common.c
> I tried not to violate any licence and only re-use freeware, but don't
fully comprehend these licences. Can these licences collide?
They can, potentially. The one thing I spot-checked was the icon page, and I
didn't see any license information there.
> Are the credentials in the about box and the manual are sufficient :-)
I'm not sure where the About box is defined. The manual looks okay, although
I wonder if the app code falls under the blanket "all rights reserved"
clause: http://www.codeproject.com/info/TermsOfUse.aspx

It probably comes down to whether this code is boilerplate for all win32
applications with an icon. I'm not the right person to make that
call.
> Fix blocking issues for a first launch. My testing setup is limited (I only
have Eaton UPSes). Feedback from others is really needed.
One way to test your code is to use the dummy-ups driver with the sample data
files provided. data/evolution500.seq simulates an MGE/Eaton Evolution 500 going
on battery, then to low battery, then back online.

Of course, feel free to solicit testers with actual hardware. But with
dummy-ups, you can basically simulate various combinations of variables, and
there are many different examples in the list archives (search for
"HCL"). Here's more information on dummy-ups:
http://www.networkupstools.org/docs/man/dummy-ups.html
> Code cleanup; I like the idead to reference original NUT code (remove the
duplicates in my project. I re-used the ported NUT files from WinNUT)
I CC'd Frederic Bohe who worked on the NUT windows_port branch. Perhaps he
has some suggestions. The windows_port in his GitHub repo is different than the
original one we converted from SVN, so I don't know the current status of
that porting effort.
> Looking forward to work with the development team
>  
> Eric Kreuwels
-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20131016/f4eb5d31/attachment.html>

Hello Charles and Eric,

The windows_port branch on my repo is mostly a rebase on latest master. I still
have some work on this before pushing and of course not enough time for it.
Anyway the branch on the official repo should be functional.
But I guess the main issue if you want to reuse the windows code is that it has
been written to be compiled in a MinGW environment, not with MS building tools.
So you will probably have to modify some NUT code anyway.

Regards,
Fred




________________________________

________________________________


From: Nut-upsdev [mailto:nut-upsdev-bounces+fredericbohe=eaton.com at
lists.alioth.debian.org] On Behalf Of Charles Lepple
Sent: jeudi 17 octobre 2013 02:01
To: eric kreuwels
Cc: nut-upsdev list; Frederic BOHE
Subject: Re: [Nut-upsdev] UPSC based Windows Client

[Please remember to copy the list.]

On Oct 15, 2013, at 8:45 AM, eric kreuwels wrote:


Hi Charles

Thanks for your answer. Good questions/suggestions. I copied both the WinUPSC
and the installer project on my GDRIVE and shared it with you:
https://docs.google.com/file/d/0B0mSjYYj84-6ZGM4MWZfMnFxbUU/edit?usp=sharing

Archiving WinUPSC in the NUT GitHub would be my preference. Delivery as part of
te Windows distribution is basically a separate decision for you guys.

Steps I have in mind:

  *   Check how WinUPSC will is perceived by the other developers! Then decide
to setup a project in NUT GitHub
  *   Maybe a good idea to have a code review:

     *   Especially how I modified the UPSC code for polling. For example how
standardized is the parameter list? I made assumptions here.
I haven't diffed your code against either NUT or WinNUT, but after a quick
check, I'm not sure I understand your question here. If you are referring to
the UPS variables, there is no guarantee that a specific variable will be
available (except "ups.status"; think of a contact-closure UPS which
can only report OL/OB/LB).

As an aside, in upsc.c, you use sprintf() with strlen(). There is a
snprintfcat() utility in common/common.c

     *   I tried not to violate any licence and only re-use freeware, but
don't fully comprehend these licences. Can these licences collide?
They can, potentially. The one thing I spot-checked was the icon page, and I
didn't see any license information there.

     *   Are the credentials in the about box and the manual are sufficient :-)
I'm not sure where the About box is defined. The manual looks okay, although
I wonder if the app code falls under the blanket "all rights reserved"
clause: http://www.codeproject.com/info/TermsOfUse.aspx

It probably comes down to whether this code is boilerplate for all win32
applications with an icon. I'm not the right person to make that call.

  *   Fix blocking issues for a first launch. My testing setup is limited (I
only have Eaton UPSes). Feedback from others is really needed.
One way to test your code is to use the dummy-ups driver with the sample data
files provided. data/evolution500.seq simulates an MGE/Eaton Evolution 500 going
on battery, then to low battery, then back online.

Of course, feel free to solicit testers with actual hardware. But with
dummy-ups, you can basically simulate various combinations of variables, and
there are many different examples in the list archives (search for
"HCL"). Here's more information on dummy-ups:
http://www.networkupstools.org/docs/man/dummy-ups.html

  *   Code cleanup; I like the idead to reference original NUT code (remove the
duplicates in my project. I re-used the ported NUT files from WinNUT)
I CC'd Frederic Bohe who worked on the NUT windows_port branch. Perhaps he
has some suggestions. The windows_port in his GitHub repo is different than the
original one we converted from SVN, so I don't know the current status of
that porting effort.

Looking forward to work with the development team

Eric Kreuwels

--
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20131017/ad426a55/attachment-0001.html>