[Nut-upsdev] 2.8.0 roadmap [jNUT]

[Arnaud Quette]

Hi Emilien,

I've had a few neurons spinning on this thread, resurrecting an old
discussion with Charles...


>  In general:
> As the current client API is a little too low level to be interesting to be
> wrapped to Java (and others), is there more interesting to develop a higher
> level API in C (like in Python) and to wrap it many languages (java but not
> only: python, perl and many others can be targeted) with a tool like SWIG (
> http://swig.org/ ).
> Two linked benefits can be gained from such approach :
> 1- A common API can be distributed over all languages and rely on an unique
> implementation, which make them more visible and clear than many rewrites in
> each languages.
> 2- When you augment the API (like adding a method), all languages benefit
> of it with least effort (just running again the generation tool).
>
> In java specific wrapper:
> In term of distribution : platforms which provide package management can
> easily resolve dependancies between wrapped client pack and "native" one; on
> other plateforms (like windows) project can build and provide a "big"
> stand-alone jar with "native" client build for all plateforms (Windows
> x86/x64, Linux on many plateforms and so on...) or dedicated "light" jars
> for many plateforms (windows/linux, x86/x64/arm ...). This can probably be
> provided automatically with smart commands on buildbot.
>
> In my developer point of view:
> I think it is more interesting for a developper to implement a high-level
> API than a simple communication protocol rewrite.
> I think also it is more valuable at long term for the nut project.
>

from a QA standpoint, this is fully valid and relevant: having 1
implementation (ie the main C one) that serves to generate the language
binding is totally in the mood of the USB helpers, AsciiDoc rewrite, ...

this would moreover help the current move with the scanner, and the upcoming
for the configuration:
having these 3 libs (libupsclient, libnut-scanner and libnut-config)
providing the base services, and allowing to generate the bindings for
Python, Perl, Java and whatever other language that is not yet supported, is
a very good approach!

the only issue for now is that libupsclient is still too low level.
for this project to be useful, we have to consider the whole needs, and the
API provided.

Any thoughts?

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110628/55d05442/attachment.html>