[Nut-upsdev] 2.8.0 roadmap [jNUT]

[EmilienKia at Eaton.com]

	2011/6/12 Charles Lepple <clepple at gmail.com>
	

		On Jun 12, 2011, at 12:48 PM, Arnaud Quette wrote:



			2011/6/12 Charles Lepple <clepple at gmail.com>
			

				On Jun 11, 2011, at 3:53 PM, Arnaud
Quette wrote:
				
				

				 * jNUT Java binding
				   the exact content of this task is
still to be defined, but this should include native client access and
NSS support,
				   the following will be considered with
a lower priority:
				     - device discovery (JNI using
libnut-scanner),
				     - configuration (using Augeas)
				     - mDNS discovery
				   I'm currently checking resources
staffing with Eaton
				


				I'm not a huge fan of Java to begin
with,


			so do I.
			but having played with Android a year and a half
ago, and having some requests more recently made me think we are still
lacking a Java binding...
			 

				but if I had to interface a Java tool
with NUT, I wouldn't want the hassle of native bindings (i.e. JNI)
unless it was absolutely necessary. Most of the NUT protocol should be
easily implementable in pure Java (including SSL).
				


			indeed, native client access (ie implement the
ascii NUT protocol in Java) is easy enough to be implemented directly
(as we have in Python, Nagios plugin, ...)
			


		Ah, I think we're saying the same thing. IIRC "native"
in terms of Java is the underlying processor/OS, and I think you are
describing a "pure Java" implementation.


	indeed, so let's go for native ;-)
	
	cheers,
	Arno
	
	 

Hi all,
 
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/ <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.
 
My two cents.
BR,
 
Emilien
 
 

--------------------------------------------------------------------------
-------------- section suivante --------------
Une pi�ce jointe HTML a �t� enlev�e...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110614/f1597039/attachment-0001.html>