| |||||||||||||
GNOME Platform StormcloudsGNOME Platform StormcloudsPosted Mar 26, 2004 12:20 UTC (Fri) by massimiliano (subscriber, #3048)Parent article: GNOME Platform Stormclouds
Many of the previous comments are correct, but seem to miss one main point... The issue here is not "let's write GNOME applications in Java/C#/ Perl/Python/Ruby". This is something that can be easily done now, with any of those languages. The issue is "let's integrate a virtual machine in the GNOME system libraries, so that GNOME reusable components can be written in a language that is more abstract/expressive/safe/productive than C". The issues about the type safety of languages, IMHO, should be looked at from this perspective. In some cases it is perfectly appropriate developing an application in a language that is not statically type safe, while in other cases it is better to have a type safe language. Each application developer can pick his own choice, and be happy with it. It can be also perfectly acceptable to have different VMs supporting different languages for different applications. On the other hand, for reusable components, the requirements are more stringent. Moreover, if you want to have true reusable components, ease of interoperability with other technologies is a must. What Microsoft is doing internally, with .NET, is replacing COM and DCOM as a technologies for writing components with a more modern way of doing things (.NET assemblies and remoting). They will have the advantage of a very coherent system when the migration is completed (longhorn), and a very easy and incremental migration path for ISVs in the meanwhile. If I got it correctly, it is because he was seeing this potential in the .NET standard that Miguel started the mono project; he tought that those benefits would apply to a free platform (GNU/Linux/GNOME) as well. In my opinion, for individual applications the problem of "standardizing on one VM" is not an issue. Each application writer picks his own choice, and everything works anyway, just like we are doing now. It is when you want to have a coherent system, and reap the benefits of a more modern platform also at the system component level, that you need to pick a choice globally to avoid fragmentation. At this point, the only options are Parrot, Java and mono (for the sake of completeness, also portable .net, but this counts as a .NET reimplementation like mono). Everybody has his opinion on the subject... for me, Parrot is not ready, and Java is not free enough. Besides, .NET is very, very well tought out, and generally technically superior.
(Log in to post comments)
GNOME Platform Stormclouds Posted Mar 27, 2004 14:48 UTC (Sat) by mly (guest, #2171) [Link] Good points. My nagging worry with .NET is that Microsoft might get a chance to mess things up for us in the courts...Just a few days ago, the European Union decided that Microsoft has to pay a big fine for having restricted competition and they are forced to open up their APIs. The coin has a backside though... "Because Microsoft will be allowed to pursue royalty revenue from the APIs it publishes, Jeremy Allison says that the projects such as Samba, which he jointly leads, may face a prohibitive hurdle." Quoted from http://theregister.co.uk/content/4/36520.html Are we sure no such issues will pop up with .NET? A related question: Is it really clear that CORBA is no good as an infrastructure for GNOME? Why would .NET be so much better? It seems to me that there are CORBA implementations for Linux that are much more mature than Mono, and they aren't burdenend by patents or Microsoft intellectual property. There are language bindings for all popular languages, and there are several alternative implementations.
GNOME Platform Stormclouds Posted Mar 29, 2004 8:52 UTC (Mon) by massimiliano (subscriber, #3048) [Link] "Because Microsoft will be allowed to pursue royalty revenue from the APIs it publishes, Jeremy Allison says that the projects such as Samba, which he jointly leads, may face a prohibitive hurdle." Quoted from http://theregister.co.uk/content/4/36520.html Are we sure no such issues will pop up with .NET? The main reason why this is not an issue for GNOME is that .NET (and, more importantly, mono) is not a monolithic thing, kind of "all or nothing". Miguel tried hard to explain this, basically there are three large pieces in mono: the ECMA core, the Microsoft APIs reimplementation, and the Linux/Unix/GNOME APIs bindings. The only piece that can have some issue (in the sense you mention above) is the reimplementation of the Microsoft APIs, and it is totally unrelated with the other big chunk of APIs (the Linux/Posix/GNOME ones). This is something very important: the only thing Microsoft can do is create difficulties in emulating the Windows APIs, which are needed only if you want to run .NET applications "conceived" for Windows. In mono, we are creating a different "stack" of APIs, that give access to the Posix world, GTK+, Mozilla, Evolution, and ultimately all the GNOME libraries. On these, Microsoft has no rights at all. Of course software patents are a different issue... but those patents would have to apply to the GNOME libraries themselves, and therefore would be a problem even today, and without mono (I hope you get the point, otherwise feel free to ask for a clarification). Is it really clear that CORBA is no good as an infrastructure for GNOME? Why would .NET be so much better? Hmmm... CORBA is just like a specific application of .NET remoting, and just that. .NET is much more powerful, it is a whole platform for software developing and execution. In simpler words, CORBA has no bytecode and virtual machine definition, and no real class libraries. It is just a way to define remote interfaces, with one protocol to have them talking each other, and the specification of language bindings to use these interfaces. In fact, GNOME components (Bonobo objects) are based on CORBA, and the result is not so exiting. The KDE guys started with CORBA, too, but then sow how bad it was for in process desktop components, and threw it avay, going for a "propriatery" component system (KParts) which works very well ("propriatery" because they designed it themselves, it is not based on any existing standard, but of course it is free software).
So, .NET would be better because it would be a real platform to write code, not just a way to specify abstract interfaces that turns out to be overkill and cumbersome to use for in-process components. And mind you, I have always liked CORBA a lot, it is simply not a tool for this job (and, by the way, you could also have CORBA objects in .NET if you really wanted so, at least in principle, but it seems to me that current IIOP implementations are not yet "carrier grade").
|
|||||||||||||