Hi Charles,<br><br>back from vacation since Tuesday, but still not really on NUT yet...<br><br><div class="gmail_quote">2012/9/5 Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com" target="_blank">clepple@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[I took the liberty of replying on nut-upsdev - not many people are using github yet since the NUT repository native format is still SVN.]<br>
</blockquote><div><br>I've asked Emilien to also present this on nut-upsdev, and point the "pull request" on github.<br>but you've probably been faster than him ;)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Sep 4, 2012, at 10:17 AM, Emilien Kia wrote:<br>
<br>
> This is a proposal for a new client library which scopes an higher level than the existing libupsclient.<br>
><br>
> It needs less dependencies to be compiled than the libupsclient and can be easier to integrate in other projects (including on windows with visual studio projects). The original need for this library was to have a minimal platform to integrate in Balooloo/hazelnut to communicate to upsd on Windows but which can be easily statically compiled on VS.<br>

<br>
<a href="https://github.com/balooloo/hazelnut" target="_blank">https://github.com/balooloo/hazelnut</a><br></blockquote><div><br>this is also in line with providing high level APIs for all languages.<br>Java, Perl and Python are in good shape.<br>
but the current libupsclient is historically just NUT internal lib, made available for external clients (starting with wmnut).<br>so, this is something I had in mind for long (I've probably some more, not tracked on Alioth or elsewhere)<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> It is developed in C++ with a wrapper in pure C, inspired from jNut API.<br>
> Its object model targets a client/device/variable/command model rather than a network query/answer.<br>
> Client is an interface class which declare methods to manipulate devices, derived classes are implementations (actually only TcpClient for TCP based current protocol) to support specific communication channel (perhaps we will have DBUS, message busses or others in a near future).<br>

> Device, Variable and Command classes are helpers to easily manipulate such concepts.<br>
<br>
Is the Doxygen support complete? I didn't see a Doxyfile in the patch. It might also be good to have some high-level documentation, and possibly some example code (even if it is just embedded in the comments - but unit tests would be even better).<br>
</blockquote><div><br>2nded.<br>but I'm sure Emilien already planned all that ;)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are also some references to "NUTD", which I think means "upsd".<br></blockquote><div><br>on my request, maybe too much anticipating 2.8 / 3.0...<br>the name lib*nut*client  is also part of the naming evolution.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Actually, libnutclient support all features of libupsclient excluding only SSL support. I will develop it soon when integrated in nut trunk.<br>
<br>
So should we wait to merge this until the SSL branch is merged?</blockquote><div><br>good question!<br>@Emilien?<br><br>on the NSS side: my last merge attempt (1/2 an hour, 2 weeks ago) miserably failed.<br>BTW, I took the liberty, at that time, to dump and update NUT SVN DB on Alioth, to finally benefit from the "svn merge --reintegrate" command, which was not previously available. There was a 1 minute unscheduled (and not announced) downtime on Svn on Aug. 17th!<br>
But still, the reintegration merge failed.<br>my current stance is... well, undefined, due to the lack of time to thoroughly analyze and understand the situation.<br>Ideas and comments welcome, but in a separate thread.<br>
<br>a final thank to Emilien for his great work on this!<br>
<br>cheers,<br>Arnaud<br></div></div>