On Nov 26, 2011, at 11:29 AM, Arnaud Quette wrote: > 2011/11/25 Charles Lepple <[email protected]>: >> On Nov 25, 2011, at 9:59 AM, Arnaud Quette <[email protected]> wrote: >> >>> Any comment from your side on a possible integration in the trunk? >>> I'm too biased to consider my voice relevant here... >> >> You think I'm unbiased? :-) > > probably more than me on this point, at least for the public ;-) > but I'm conscious that this merge would be part of the gesture of > appreciation toward Eaton...
I guess it would be a gesture of appreciation towards Eaton, but as you mention below, people are primarily directing their requests for this sort of library to Eaton, not towards the NUT project. You are essentially asking for the rest of the project to bear the maintenance burden for some alpha code that doesn't really benefit the project much. We have already seen this sort of increased maintenance burden from the Win32 binaries (which aren't quite to the point where they can easily be built by users outside of Eaton). >> I haven't had much of a chance to look at the code, > > once you've trimmed the doc, there doesn't remain much apart from the > build rules. There may not be much, but now we have even more duplication of dstate-related code. I think it would be best to hold off on merging until we come up with a cleaner middle layer for this HAL/dstate/libeaton stuff. >> but by default, I am skeptical of libraries which try to abstract away all >> of the complexities of bidirectional communication with hardware. I may have >> missed this in the documentation, but what problem does this solve that >> isn't addressed by the rest of NUT? Is this intended for GUI apps? If so, >> how does this interact with event loops or threading? Have full-fledged apps >> been written against this API? > > none apart from the examples in the doc. > the aim is to provide a simple solution to a simple problem: what if > people just want to get ups.status (and possibly a few more) in their > "god" app, in order to act smartly. I've had so many requests of this > type, since the old MGE time, you'll never know! > some people only use drivers and interface with these. > some use the whole framework and other only a handful of data and a lib. > all this is simply NUT drivers available as libs (Ie, we have only > removed main.c!). no more, no less. > all NUT limitations still apply. and the user needs to reimplement NUT > driver main.c on his own. Maybe a diagram would explain this better? Does a user essentially compile driver code into their app, hardcoding it to a single device type (USB HID, SHUT, XML, etc.)? Or does the libeaton-based app have all drivers available? I think I know how this works from reading the code, but if my experience with libhid has taught me anything, it's that nobody looking for an easy solution will ever read library source code (no matter how much you declare it to be a simple wrapper around another library). >> I don't personally see any urgency to merge this into the trunk, but I am >> willing to be persuaded otherwise. > > well, the only urgency I see is that it increase the sync overhead > around branches on my small Eaton team. > also considering that Fred will be on paternity leave soon, this waste > work force that could be used otherwise. Not sure I follow this reasoning. If the code is mostly independent of NUT, why can't the branch just wait until we're not rushing to get another release out the door? Especially if we're considering moving to Git for our central code repository, where rebasing the branch on top of the trunk should be fairly effortless. > I'd like to get this small one done for 2.6.3, so that we can then > concentrate on windows + nss merges and "bindings" improvements. and > also in order for me to concentrate on these infrastructure and cloud > integrations. I think it needs some work before merging, especially considering your proposed short timeline for 2.6.3. I can't find a link to one of the "how to write a library API" guides that I think would be very applicable here, but as I alluded to earlier, this is going to be difficult to integrate with a GUI or multiple threads (and Win32 programmers love threads). This goes back to the whole global state problem. Also, you probably want to clarify that we only work with libusb-0.1(.12), and that libusb-compat may cause problems. Plus, this is a good place to document the whole "your distro probably has a -dev splitoff" problem. The recommended version numbers for the other libraries (or at least the versions you tested) would probably be useful to have in the documentation as well. _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
