Slashdot Mirror
Mono Ships ASP.NET server
Miguel de Icaza writes "We have just released the new version of Mono the new version includes a working version of ASP.NET. The release includes a sample web server that "hosts" the ASP.NET runtime (it can be hosted anywhere, for instance in Apache, with mod_haydn). The web features of ASP.NET would not be very useful without the support of a backing database. The new version of Mono includes database providers for Oracle, MS SQL, Sybase, ODBC, OleDB, Gnome Data Access, SqLite, MySQL and of course, Postgres. The C# compiler is now 37% faster due to some nice optimizations on the JIT engine and in our class libraries. You can use it to develop GUI applications using Gtk#. Screenshots for mPhoto and the GUI debugger (which can debug both JITed apps and native applications). "
It's a weird experience to run the same exe in Windows and Linux with the .NET or Mono runtimes. When Mono supports WinForms (by translating them to Gtk#), so GUI apps written with Visual Studio .NET's GUI builder work on Linux, that will be significant.
Although there is prior art examples of individual technologies such as the JVM etc, Microsoft patents such as the one mentioned, define and claim the interoperation of the components, in such a way that any re-implementations will be sure to be covered by the patents. This remains true even for the Microsoft specs submited to standard
In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA . Sun has also fully pened up the Java development standards process under the new Java Community Process (JCP). Even to the point of granting full open source re-implentations of J2EE such as JBoss...
There those that claim that .NET is open to re-implementation, but until Microsoft make a simliar public legal declaration to Sun's JSPA, any .NET reimplementation represents a pending legal mindfield.
Just like Microsoft is outspending the Apache Foundation?
Sun/IBM/BEA/Oracle/Apache.. Microsoft may well pull it off, but it's hardly a foregone conclusion.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
It doesn't sound like much, but for porting a lot of business logic to Linux, this is a potentially huge development.
Another thing that's needed to get this project up to par with MS .NET is an IDE. Fortunately, the SharpDevelop
folks are working on that...
So far this project has been very impressive. Kudos to the Ximian folx.
Finding God in a Dog
Mono today works on LinuxPPC in interpreted mode, but does not work on MacOS X since the calling conventions are not the same.
We started work three months ago on a new JIT engine whose main aim was portability (although the current JIT can be ported, most optimizations and coarse-opcodes had to be reimplemented over and over). The new JIT engine design has two intermediate level representations: a higher level one, and a low-level that can be as precise as required for a target CPU. The funny thing is that the new JIT is actually faster JITing code than the current JIT even with the added layer.
The lower-level layer is actually something we are very proud of, Paolo architected a register allocator and instruction scheduler at the same stage, and we are using the PowerPC on MacOS X as the second platform to target to guarantee this time that the JIT is actually easy to port.
We are hoping to release the new JIT engine in February/March.
The volume of database providers in this release is the work of very few but very active hackers: Brian, Dan, Rodrigo, Tim and Ville. It is amazing the amount of code that these hackers pulled in the last two months.
It is easy to know when the System.Data hackers are working, your inbox gets hammered with patches from the mono-patches list.
You can help us support DB2, but you will have to get your hands dirty and start coding like the crazy hackers that brought all these providers (and Reggie has agreed to contribute his optimized provider as well).
Well, having ASP.NET is very convenient to move applications and components from Windows and deploy them on Linux or Unix systems. So I think that this is a plus on its own.
.NET offer a very interesting crossroads: the possibility of sharing components and existing classes independently of the language that was used to create it.
In terms of choices, I have to admit that I personally am more of an old school strongly-typed kind of person, and I like programming more with a language that I understand like C#. There is nothing wrong with PHP or Perl, but I feel a bit insecure with them. Like when you have to order water in a restaurant, and you do not want to look cheap, so you end up asking for `bottled water' even when you are trying to not spend a lot of money [1].
Mono and
I strongly believe that scripting languages are great for quickly building web solutions, and I would love to see more work between the PHP (and other scripting communities) and Mono. We are certainly interested in helping out.
For instance, the Mono runtime is easily embeddable, it could be used in existing systems with ease: for example, allow any language but use the PHP API to write web pages is one option (check the link for a few more samples and the tutorials), or hosting any programming language on Apache (as its done with the Apache/Mono module mod_haydn.
Miguel.
[1] Although as you grow older, you become more cynical, and you just tell the waiter `Get me a glass of the cheapest form of water you have'.
Good thing a:
If we can get a better "forms" implementation on 'nix (windows-like without windows bugs), that would be awesome
Secondly, but verrry important to those who do webhosting, clients requesting ASP pages would be able to run on 'nix servers, no longer requiring special windows dedicated hosts. For those who prefer 'nix servers, and many hosts do, running a windows server in the bunch is a pain in the butt!
If this actually pulls through, I will be amoung many who are very, very impressed.
The "contract" for language interoperability is called the Common Language Specification (CLS) and furthermore, languages are divided in CLS producers, consumers and consumer/producers.
You can think of the "CLS" as a richer contract than say the CORBA IDL or the COM IDL: they define APIs. Now on top there is a virtual machine that allows you to run either native code or "CIL" code that executes on the common runtime.
There are plenty of CIL compilers (C, C++, C#, JavaScript, Fortran, Cobol, Eiffel, Ada, VB, Haskell) that can produce/consume CLS code.
It is great if your language can produce and consume CLS classes, but its also good it it can consume them, because then a large body of code is available to you.
Miguel.
I am going to try.
.NET Framework is actually a new platform for software development, and incorporates many ideas that have been floating around before.
.NET Framework includes basically three components: programming languages, a common language runtime and a set of class libraries for acomplishing various kinds of tasks.
.NET Framework offers a couple of ways of doing distributed computing with RPC calls: one is called the Remoting framework and the other one is called Web Services (its not exactly like this, but for now this will work).
.NET Framework has some tools as well for making it easy for developers to write client and server applications using the web services protocols.
.NET does is it simplifies the development of COM components and the use of COM components (there is plenty of literature on this subject on msdn.microsoft.com).
.NET makes them more productive. You wont loose a lot by trying it out, you can always go back to your current tool set if you do not like .NET.
The
The
The framework was designed so multiple programming languages could share the same set of class libraries with minimal effort, and also to allow a large set of programming languages to work together rather than having each one create its own "micro platform".
Now, the
Remoting is the closest thing to a CORBA replacement, but its not a great replacement. I personally like CORBA more for plenty of reasons that I hope one day I will write down.
Web Services is the "in" thing to do today, so the
Another things that
Most COM developers I have talked to claim that
Miguel
Sun's patents, if anything, look much more worrisome. For example, patent 6,477,702 patents the basic Java bytecode architecture and can be used by Sun to shut down any competing implementation. Furthermore, despite lots of cheery announcements, there is no indication that Sun has made a legally binding commitment to license this patent freely for open source implementations, let alone competing commercial implementations. The way it looks to me is that Sun is just stringing the community along with promises, and they will change their tune when they feel that they have established a secure enough market position. Sun has broken lots of Java-related promises; they are not to be trusted either.
Let me start by saying that programming COM objects is the most retarted way of programming functionality. True, using VB or Delphi, it is easy, but using f.e. C++, it's not. Read Don Box' book Essential COM to see what I mean.
.NET is kind of like the enhancement of what automation was set out to be: a common way for any COM object abiding to automation rules and specifications to be able to use the environment (such as data, variables etc) of the application without doing 'marshalling conversions' when switching between languages? (for example: using variants and safe arrays to access data both in C++ and VB). .NET is the replacement for the VB runtime for VB programmers, the C(++) Runtime / STL / Win32 lib for C/C++ programmers etc. It's the general target platform for _ALL_ CLS compliant languages (C#, VB.NET, J#, JSCript.net etc. C++ is partly CLS compliant, if you want to use templates or multiple inheritance, you can't).
.NET. The objects you create, run inside application domains, which is totally different than COM objects do, in relation to the SCM.
.NET, but its harder). Webservices is not a 'part' of .NET, you can build webservices WITH .NET. That's a different thing!
.NET api is the key of its success. Add to that the wonderful ASP.NET functionality (which is really years ahead of anything else) and the very good documentation of the API and you're set.
.NET and the amazing security featureset available to a developer and 2) that COM IS one of the causes of security leaks and DDos attack possibilities, simply because people forgot to use smartpointers and kept memory nonfreed. This is over now.
COM as a functionality is great, but it should have been more transparent for the developer, like VB did this: you just program classes and hey, check it out, they're COM objects now!. Using Visual Studio, creating COM objects was (at least using ATL) a bit painless, but don't try it using f.e. UltraEdit32 and no helper library.
So if I understand you correctly,
No.
The multi-language part is not a result of 'making it a better marshaller' or better 'automation platform', but simply a result because now all languages have the same API, the same functionality on board: it doesn't matter which language you pick, you can target the same API and use the same cool functions with ease in VB.NET as you can in C++.NET.
As a result of this, the code you compile will run in a VM. This VM, the CLR, is the heart of
Webservices is a term for a piece of 'logic' as I call it. Functionality. It's not 1:1 projectable on a piece of code, like 'that class can serve as the base class for all webservices'. This is due to the fact that a webservice, when you use SOAP f.e., depends on a lot of tiny building blocks to do whatever it should do. That's why it couldn't be another Interface. (I also doubt what that would have brought to the plate, you can create webservices using the new ATL extensions and using plain C++, thus not
About the productivity: Now people can use a language that suits their needs and preferences (f.e. I prefer C# over VB.NET, while I've developer a lot of COM objects for n-tier systems in VB) and use a much richer API than they ever could. It doesn't depend on MS' tools. Sure the new VS.net is great, but the rich
Also I don't see your kick in the balls towards IIS style security. To me this sounds like you really do not understand 1) the power of the strong typing inside
Never underestimate the relief of true separation of Religion and State.
This guy is 100% correct.
.NET/Mono, Microsoft turns around a sues them for royalties.
I talked to my high school buddy who was a patent attorney, but who quit the business because he hated the whole business of IP law because he was morally against it.
I asked him what could happen, and theoretically, depending on the strength of the patents, Microsoft could sit back and wait for Mono to be developed, wait until a critical mass of applications gets developed on it, and then start charging royalties to anyone using that technology.
Unless someone clarifies the legal status of Mono in regards to Microsoft's patents, this is 100% definitely the situation that will occur.
Think about it, it is exactly what Rambus tried to do with SDRAM. Microsoft is a business and looks to Linux as a major threat. It is a jackpot for Microsoft in two ways:
1) They get the Open Source schmucks to do their work for them
2) Once a bunch of businesses have implemented their business on
We need to get a legal clarification of Mono before any real development starts occuring. My guess is that it is stepping on a whole shitload of Microsoft patents, and it is the onus of the implementors (ie. Ximian) to make sure that they develop around those patents, or 1) be prepared to try to quash the patents or 2) pay whatever royalties Microsoft charges.
A very succinct explanation I got while on a .NET training course was that .NET reversed something that Microsoft got wrong:
COM: A very lightweight wrapper for intra-machine communication. Low overhead and fast. Forces programmer to handle all other issues like memory management, implementing interfaces etc. etc.
COM+: A heavyweight framework for inter-machine (remote) execution. Tries to do all things and as such suffers from being ghastly to set up and use
In short
COM: Light for local machine execution
COM+: Heavy for remote execution
Microsoft decided they got this completely wrong and have reversed it
dotNET local machine: Uses a CLR and common type system. This handles all memory management etc. etc. inside a virtual machine making things easy for the coder (with overhead of course)
dotNET remoting: Has become very lightweight. You just send XML soap messages over TCP. That's light and that's also what web services are based on. Can you imagine even considering web servicse with COM+ ?
So that's what they've changed in terms of COM/COM+. Having used it, I'm glad I never have to touch COM+ again and I'm glad that Microsoft have realised that a java style CLR/VM works well for general programming
If we can get a better "forms" implementation on 'nix (windows-like without windows bugs), that would be awesome
GTK+'s "forms implementation" is more advanced than Windows's. When you design a form, you can specify the size of cetain controls, and let GTK work out the sizes of other controls automatically on the fly. This gets round the problem that you see on Windows where if someone changes their display preferences to use "Large fonts", some text doesn't fit within the fixed sized label that the form has. With the GTK model, the label and other controls around it would resize automatically so the text fits in perfectly.
Also, you can specify how controls on a form should be a aligned, and the alignment it handled by GTK, so you don't have to place controls on the exact pixel you want them to appear on (which is related the the previous problem). Yes, I know you can "snap to grid", but that still messes up with non-standard sized controls and in the scenario mentioned above with large fonts. I could just say "It's similar to the way Java handles GUI design", but I'd see all the Windows GUI designers respond with "but Java's UI looks horrible". On a system running only Gnome or similar, GTK is what all programs use, so they all look the same - none of this horrible inconsistency you see on Windows. GTK handles the themes or skins, so if the user doesn't like the look of your app, they can change the theme, and all apps still look the same as eachother. I know XP can do that, but dev tools on XP won't let you design a form in a GUI point 'n' click environment that follows GTK's ideas of automatically placing and aligning controls on the fly.
As someone who's spent a bit of time creating programs with user interfaces in MFC, Java and GTK, that is my opinion. Now, do you still think that Windows has a better "forms implementation" ?
Follow me
* A bunch of web pages do not constitute a legally binding contract.
That is certainly true. A contract is a quid-pro-quot between two parties where each side assents to give up some form of consideration to the other.
On the other hand, patents and copyrights do not require a contract to use -- they only require a licence. A licence is a unilateral grant of permission. Any unambiguous statement granting permission suffices, so while you are correct that their grant is not a contract, it is a licence and your point is offbase.