Re: Putting the 'Mono debate' back on the rails



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]