RE: [Xen-API] RE: Xen API - Java RPC Binding (hlebegue)

["hlebegue" <hlebegue@xxxxxxxxxxxx>]

Hi Brian. I second this initiative. It could be better if your
enhancements can make it into XenSource so that the two stacks do not
compete. And maybe the XenServer specific APIs could be split from the
source, as an attitional plugin/extension. 

I do not know if Citrix is driving the development of the Xen Source or
how hard would it be to refactor it. 

The Java Bindings should be made one of the standard bindings
distributed along in an SDK. 

Hope this helps

Hugo

-----Original Message-----
From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-api-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dealy, Brian
Sent: Thursday, November 13, 2008 7:17 PM
To: xen-api@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-API] RE: Xen API - Java RPC Binding (hlebegue)

Hi,
The way I understand the current situation there is an API to XMLRPC
that is part of the xenServer product line. This java api is not
actually 100% compatible with the api (and the xend code )  from xen.org
. (I have verified this) 

I have an interest in having a java API which would be available for the
open source version (not tied to XenServer) and was thinking that if no
one was working this, I might be interested in contributing some time
towards it.  I have some ideas about how this might be done, but not
having been a part of a community development project, I am not sure
about how the process flows.  

I have taken the XenServer java api and done some  mods based on the
python source and the API spec, Xen Management API dated 24, july 2008
(Stable release) and have been having some success using it to
manipulate and retrieve values via xmlrpc. I am assuming that this is ok
for my early testing, but would like to share with the community if
possible.   I have had to change some of the method signatures, of
course since they are different.  I haven't
kept a list of diffs, etc. and the code is not a 100% tested, validated
to be faithful to the spec above.  but 
I would be willing to make it available. ( I might need to spend an hour
or so refactoring the package names)


But I would like to know if there is anyone working on the open source
xen java bindings and if not, whether
there would be interest in having them become a separate project under
xen.org.  I am not sure what the process 
is for contributing to the xen community as a developer so any insights
there would be useful also.  I would
be willing to take the lead on getting started if no one else is working
this.

things that might make sense to talk about are:  
Should the API be tied to the api for XenSource.com's open source sdk
java bindings?
if so, what is the mechanism that would be needed to maintain separate
trees because
of the different feature sets they currently support?  

Does anyone know if the current xen-api and Specification are auto
generated to any degree? they definitely seem like a candidate for code
generation from a common spec of some sort.  (could be useful for other
bindings as well)

Any discussion is appreciated.

regards,

Brian Dealy

dealyb@xxxxxxxx










Date: Mon, 10 Nov 2008 15:26:56 -0800
From: "hlebegue" <hlebegue@xxxxxxxxxxxx>
Subject: [Xen-API] Xen API - Java RPC Binding
To: <xen-api@xxxxxxxxxxxxxxxxxxx>
Message-ID:
        <133A1C67A2D4284A91A113F4D951E8DAA87C9F@xxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

I found some old references to a library developed in Cambridge UK for
which the link is no longer active  

http://www.cl.cam.ac.uk/~tw275/java-binding-source.tar.gz 

http://www.cl.cam.ac.uk/%7Etw275/java-binding-source.tar.gz

 

I also found a sample using the Apache JavaRpc client on the slides on
the Wiki

 

Has anyone developed a Java library that wraps around the Rpc bindings
to expose the XenAPI ?

 

Thanks in advance

Hugo Lebegue

 

CONFIDENTIALITY NOTICE: This communication with its contents may contain
confidential and/or legally privileged information. It is solely for the
use of the intended recipient(s). Unauthorized interception, review, use
or disclosure is prohibited and may violate applicable laws including
the Electronic Communications Privacy Act. If you are not the intended
recipient, please contact the sender and destroy all copies of the
communication. More information at http://www.toolwire.com

 


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api