Hi It looks like the ngen.exe project is pushing things in the right direction.
Both Java and DOT.NET fail on one account: You can't deploy self-contained, native executables with all dependencies included and no (unreasonable) external dependencies. You're simply forced to drag along an ever-changing, ever-growing runtime and classlib, that creates a dll-hell of its own kind. Every developer that I know, longs for the same simple solution: being able to deploy one, unbloated, and self-contained executable. Proprietary vendors, however, do not wish to provide such solution. They see their runtime as a platform that must stay separate from your application. They always tend to invert things. For example, I see a relational database as a persistence helper, i.e., some kind of library that I would include in my server-application. Microsoft and Oracle see it the other way around: the rdb is the executable, and your application is cut into stored procedures and runs in their executable. The same thing holds true for web servers, ejb containers, and so on. This is the platformization problem: The problem in which your application's logic is cut into little pieces and inverted to a proprietary process. It leads to major problems, because you can only reasonably invert your application to one other process. If your stored procedure runs in the Oracle container, how can it run in the Weblogic ejb-container at the same time, while conforming to the needs of the IIS-container as well? The solution would be to include all foreign logic into your own container. Only open source is sufficiently humble to put the needs of the user first and to provide this solution. My question is now: Since Mono is open-source, why do you play the platformization game? Why should any application be invoked by Mono, and not the other way around? Turn things around, and the solution not only becomes brilliant, but it will beat proprietary DOT.NET vendors' solution hands down. Mono would have strong, compelling advantages, that they cannot or will not provide, and certainly not within a reasonable time frame: - There would be no need to download and drag around a large runtime and classlibs; - there would be no versioning problem of the runtime and classlibs, because every deployed executable would have its own; - by removing unused symbols, executables only carry with them the pieces of runtime they actually need; I would suggest using the UPX executable compressor as well; - Executables run by double-clicking them; no "java -r app.jar" and other bs. - Iteroperability with Java, C++ code would not be a concern, because the executable could natively invoke gcc/gcj-produced and included dependencies. Get also rid of the notorious cygwin.dll and let developers produce native, all-included executables on Linux and Windows. You will push proprietary DOT.NET vendors out of the market by doing so. The alternative is that you provide a runtime cum classlibs download, while Microsoft includes theirs by default in the OS. The window of opportunity is not large, and now that the DOT.COM hype has ended, don't expect AOL to take over your remains for $4 billion dollar. _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
