[Nut-upsdev] [nut] High level C and C++ libnutclient (#2)

[Arnaud Quette]

Hi Charles,

back from vacation since Tuesday, but still not really on NUT yet...

2012/9/5 Charles Lepple <clepple at gmail.com>

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

I've asked Emilien to also present this on nut-upsdev, and point the "pull
request" on github.
but you've probably been faster than him ;)


> On Sep 4, 2012, at 10:17 AM, Emilien Kia wrote:
>
> > This is a proposal for a new client library which scopes an higher level
> than the existing libupsclient.
> >
> > 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.
>
> https://github.com/balooloo/hazelnut
>

this is also in line with providing high level APIs for all languages.
Java, Perl and Python are in good shape.
but the current libupsclient is historically just NUT internal lib, made
available for external clients (starting with wmnut).
so, this is something I had in mind for long (I've probably some more, not
tracked on Alioth or elsewhere)

> It is developed in C++ with a wrapper in pure C, inspired from jNut API.
> > Its object model targets a client/device/variable/command model rather
> than a network query/answer.
> > 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).
> > Device, Variable and Command classes are helpers to easily manipulate
> such concepts.
>
> 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).
>

2nded.
but I'm sure Emilien already planned all that ;)


> There are also some references to "NUTD", which I think means "upsd".
>

on my request, maybe too much anticipating 2.8 / 3.0...
the name lib*nut*client  is also part of the naming evolution.

> Actually, libnutclient support all features of libupsclient excluding
> only SSL support. I will develop it soon when integrated in nut trunk.
>
> So should we wait to merge this until the SSL branch is merged?


good question!
@Emilien?

on the NSS side: my last merge attempt (1/2 an hour, 2 weeks ago) miserably
failed.
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!
But still, the reintegration merge failed.
my current stance is... well, undefined, due to the lack of time to
thoroughly analyze and understand the situation.
Ideas and comments welcome, but in a separate thread.

a final thank to Emilien for his great work on this!

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120906/a65ae3ee/attachment.html>