On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: > * Should applications built with anything in the Bindings suite be accepted > into the Desktop suite? > - short to medium term > - do we want the central components of our software to potentially be > written in five to ten different languages and/or runtimes/platforms? > - this leads very neatly into the next question > > > * Is it time to redefine the suites and/or 'franchise' the release process? > - medium term > - this is not just about new suites, it's about redefining the current > Desktop suite by its integration interfaces and central components; we > need to make current suites serve us better before kicking off new stuff > - http://perkypants.org/blog/2005/05/19/1116533413/ (last few paras) > - start slow: don't even create new suites to begin with, just make sure > the small number of apps that want to adopt our process and standards > right now can do so - new/further governance of suites can come later Regarding just the above two issues: What if there is a bilateral subdivision of the desktop suite which helps *distributors* distinguish between applications that support being compiled AOT (C, C++, Mono AOT, Java GCJ, D?) and applications that run JIT'd/VM'd (Mono JIT, Java JRE, Python, Ruby, Perl). It seems to me that, at least conceptually if not technically, the division between the two camps above is one of AOT/native compilation versus JIT/VM'd/interpreted compilation. Notice that both Java and Mono could be in either camp depending on how the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution performance is also (generally) higher. It would be interesting to get Miguel's take on whether or not Mono AOT usage should be encouraged. In the Java GCJ case, it is encouraged for use by its authors.
Attachment:
signature.asc
Description: This is a digitally signed message part