On Wed, Mar 27, 2013 at 6:27 AM, Donal Lafferty <donal.laffe...@citrix.com> wrote: > > >> -----Original Message----- >> From: srivatsav.prasa...@gmail.com [mailto:srivatsav.prasa...@gmail.com] >> On Behalf Of prasanna >> Sent: 27 March 2013 8:47 AM >> To: dev@cloudstack.apache.org >> Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance >> >> On 27 March 2013 13:51, Sebastien Goasguen <run...@gmail.com> wrote: >> > >> > On Mar 26, 2013, at 7:29 PM, Alex Huang <alex.hu...@citrix.com> wrote: >> > >> >>> and the C# part is for the ServerResource, right ? >> >>> >> >>> I won't code this, but it would be nice to minimize languages used >> >>> in CloudStack and try to be consistent across hypervisors (as much as >> possible). >> >>> Introducing another language and some framework that may or may not >> >>> have proprietary modules/dependencies will certainly complicate the >> >>> build and the testing, and maybe even the licensing. >> >>> >> >> >> >> Actually the ServerResource part was always planned to be implemented >> in other languages. Java is a terrible platform to execute scripts for >> example. >> That's why communication between management server and the server >> resource was done in JSON. >> >> >> >> --Alex >> > >> > 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. > > WRT to licensing, I was looking for bright line rules [2]. E.g. the Master > repo only gets donated code. A process for developing rules for tools and > frameworks is what I'm looking for. > > [1] http://markmail.org/thread/q2qhbtk2ipny3r2t > [2] http://en.wikipedia.org/wiki/Bright-line_rule > >
The bright lines are easy - but aren't really enough. For it to be in our repo it must be something we can distribute under the guidelines defined by Legal. There are plenty of pages under a.o/legal that talk all about this: http://www.apache.org/legal/3party.html is one of them, but there are plenty of others. This isn't enough - and really no one can tell you ahead of time with 100% certainty the 'rules' that will allow you to not have issues. The solution here is to communicate what you want to do, before you do it, as explicitly and detailed as possible so we can evaluate the ramifications. --David
