[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@gmail
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
