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

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

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
> 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).

There are also some references to "NUTD", which I think means
"upsd".
> 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?

-- 
Charles Lepple
clepple at gmail

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>

Hi All,

as Arnaud said, Charles, you reply too fast for me ;) I have delay as
I had wanted to change my email for lists, that is done now.
> 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).
I just have written documentation in Doxygen format but I have not
tested doc generation yet. I think API doc generation is a full
project in itself so I think we must discuss of this point in another
thread.
> There are also some references to "NUTD", which I think means
"upsd".
I have anticipated the change of name for the upsd daemon when it is
referenced in the doc. On the other side, I use "nut" in libnutclient
to differenciate it from libupsclient.
> libnutclient vs. libupsclient makes a little more sense, given that
it's a completely different interface, but the new name doesn't really
reflect
> the higher-level API.
Exact
> I don't think we need a name that reflect the API level.
> in the end, we only want to provide something useful for external
interfacing and integration.
> thus, all the libs and binding will be high level.
> and libnutclient will also replace the venerable libupsclient for external
use.
+1
> > 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?
Not necessary. The library is usable as-is. I do not need SSL support
in it right now. But I think it is a needed feature so I will look at
it development in near future, but perhaps after NSS merge.
> 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)
Exact. I also prepare the API to potentially receive other
communication channels (DBUS, message busses ...)
> 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.
I think I will intend to create pass throw git to do the merge. I will
recreate a branch on my personal git from the trunk, import sources by
hand and request a pull.


Emilien