On Wed, Mar 27, 2013 at 10:27:44AM +0000, Donal Lafferty wrote: > 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]
+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. > It's both language and build tool/platform, but I get your point. Testing and building is my biggest concern. I'm +1 to David's suggestion that the ServerResource code bits are a separate git repo, which we can publish as a different release artifact. This doesn't address general build / testing though. Anyone have thoughts on this? > 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. > I'm not going to give you a bright line. Code running in the CLR is probably OK. Use of system libraries provided by MSFT is also probably OK (but I could be wrong). Use of any other libraries will need to be specifically discussed. Donal, I think you might need to do a little bit of legwork here. Have you searched the legal-discuss ML archives for discussion about .NET code and use of MSFT system libraries in that code? Do other ASF projects do .NET code? How are they handling this? > [1] http://markmail.org/thread/q2qhbtk2ipny3r2t > [2] http://en.wikipedia.org/wiki/Bright-line_rule > >
