On Wed, Mar 27, 2013 at 10:27:44AM +0000, Donal Lafferty wrote: > > > Right, and I believe that people agree that the KVM agent needs to be re- > > written in non-Java. Could we agree on how to do this, and do the same for > > Hyper-V ? > > > > > > > > > Is Iron Python a possibility? Should be supported by the .NET CLR. > [Donal Lafferty] > Let me bring the conversation back to the subject line... > > WRT to ServerResource implementation, I'd suggested using a RESTful > API to hide ServerComponent and ServerResource implementations from > each other [1] > > This left the ServerResource open for implementation in any 'native' > language. In contrast, the ServerComponent conformed to Management > Server (Java/Spring/whatever our ORM is/etc), and it is meant to be > 'generic' to simplify reuse. > > I reason that the difficulty device access for test and build, and > not language choice. Integration testing requires device access, > and some tools will only run on a particular platform, e.g. libvirt, > MSFT compiler. The language choice is secondary to this problem.
Builds: builds.a.o provides a windows slave so if the project is isolated it can still be built I think. We can check with infra on this. On developer environment one can filter based on property/profile so it doesn't build until a valid build tool is available. Test: If the service is RESTful then to some extent we can do integration testing against the agent response and the management server response. Anything beyond that will require an appropriately licensed library to integrate with. -- Prasanna.,
