[Nut-upsdev] UPSC based Windows Client

[Charles Lepple]

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