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

[Emilien Kia]

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